From noreply at sourceforge.net Wed Oct 1 01:20:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 01:20:30 2003 Subject: [Python-bugs-list] [ python-Bugs-815563 ] bug with ill-formed rfc822 attachments Message-ID: Bugs item #815563, was opened at 2003-09-30 22:32 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815563&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: bug with ill-formed rfc822 attachments Initial Comment: The following proglet gets an except with the attached message: -----te.py-------- import email import sys msg = email.message_from_file(sys.stdin) sys.stdout.write(msg.as_string()) ------------------ python2 te.py Bugs item #815646, was opened at 2003-09-30 23: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=815646&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jan Olderdissen (janixia) Assigned to: Nobody/Anonymous (nobody) Summary: thread unsafe file objects cause crash Initial Comment: Note: This may be a dupe or a generalization of 595601. Running below code snippet on 2.3.1 release and debug build on Windows 2000/XP a few times will inevitably lead to a crash. 2.2.2 also exhibits this behavior. The crashing code: ------------ import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f=open("tmp1", "w") f.seek (0, 0) thread.start_new_thread(worker, ()) thread.start_new_thread(worker, ()) while 1: pass ------------- The issue appears to be this (and similar) code sections from fileobject.c: Py_BEGIN_ALLOW_THREADS errno = 0; ret = _portable_fseek(f->f_fp, offset, whence); Py_END_ALLOW_THREADS Note that due to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS, f->f_fp can be set to NULL by file_close prior to entering _portable_fseek. Similar crashes can be observed with read, write and close itself when they are mixed with a concurrent close. Obviously, the offending python code is buggy and a lock should be used to prevent concurrent access to f. However, it seems unreasonable for Python to crash because of it. A mutex preventing concurrent access to the file object seems like a reasonable way to fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815646&group_id=5470 From noreply at sourceforge.net Wed Oct 1 02:32:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 02:32:19 2003 Subject: [Python-bugs-list] [ python-Bugs-815648 ] thread unsafe file objects cause crash Message-ID: Bugs item #815648, was opened at 2003-09-30 23: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=815648&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jan Olderdissen (janixia) Assigned to: Nobody/Anonymous (nobody) Summary: thread unsafe file objects cause crash Initial Comment: Note: This may be a dupe or a generalization of 595601. Running below code snippet on 2.3.1 release and debug build on Windows 2000/XP a few times will inevitably lead to a crash. 2.2.2 also exhibits this behavior. The crashing code: ------------ import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f=open("tmp1", "w") f.seek (0, 0) thread.start_new_thread(worker, ()) thread.start_new_thread(worker, ()) while 1: pass ------------- The issue appears to be this (and similar) code sections from fileobject.c: Py_BEGIN_ALLOW_THREADS errno = 0; ret = _portable_fseek(f->f_fp, offset, whence); Py_END_ALLOW_THREADS Note that due to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS, f->f_fp can be set to NULL by file_close prior to entering _portable_fseek. Similar crashes can be observed with read, write and close itself when they are mixed with a concurrent close. Obviously, the offending python code is buggy and a lock should be used to prevent concurrent access to f. However, it seems unreasonable for Python to crash because of it. A mutex preventing concurrent access to the file object seems like a reasonable way to fix this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815648&group_id=5470 From noreply at sourceforge.net Wed Oct 1 02:46:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 02:46:39 2003 Subject: [Python-bugs-list] [ python-Bugs-815648 ] thread unsafe file objects cause crash Message-ID: Bugs item #815648, was opened at 2003-10-01 16:32 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815648&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Jan Olderdissen (janixia) Assigned to: Nobody/Anonymous (nobody) Summary: thread unsafe file objects cause crash Initial Comment: Note: This may be a dupe or a generalization of 595601. Running below code snippet on 2.3.1 release and debug build on Windows 2000/XP a few times will inevitably lead to a crash. 2.2.2 also exhibits this behavior. The crashing code: ------------ import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f=open("tmp1", "w") f.seek (0, 0) thread.start_new_thread(worker, ()) thread.start_new_thread(worker, ()) while 1: pass ------------- The issue appears to be this (and similar) code sections from fileobject.c: Py_BEGIN_ALLOW_THREADS errno = 0; ret = _portable_fseek(f->f_fp, offset, whence); Py_END_ALLOW_THREADS Note that due to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS, f->f_fp can be set to NULL by file_close prior to entering _portable_fseek. Similar crashes can be observed with read, write and close itself when they are mixed with a concurrent close. Obviously, the offending python code is buggy and a lock should be used to prevent concurrent access to f. However, it seems unreasonable for Python to crash because of it. A mutex preventing concurrent access to the file object seems like a reasonable way to fix this. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:46 Message: Logged In: YES user_id=29957 Duplicate of 815646 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815648&group_id=5470 From noreply at sourceforge.net Wed Oct 1 03:00:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 03:01:06 2003 Subject: [Python-bugs-list] [ python-Bugs-814976 ] test_types fails on HP/UX ia64 Message-ID: Bugs item #814976, was opened at 2003-09-30 18:51 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814976&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: test_types fails on HP/UX ia64 Initial Comment: 6. Built-in types 6.1 Truth value testing 6.2 Boolean operations 6.3 Comparisons 6.4 Numeric types (mostly conversions) 6.4.1 32-bit integers 6.4.2 Long integers 6.4.3 Floating point numbers 6.5 Sequence types 6.5.1 Strings 6.5.2 Tuples 6.5.3 Lists 6.5.3a Additional list operations Traceback (most recent call last): File "/house/arbatpy/Python-2.3.2c1/Lib/test/test_types.py", line 415, in ? else: raise TestFailed, 'list sort compare function is not callable' test.test_support.TestFailed: list sort compare function is not callable The test in question is definately failing: >>> z=range(12) >>> z.sort(2) >>> (it should raise a TypeError). Anyone? ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:00 Message: Logged In: YES user_id=29957 Linux/ia64 works fine. Building --without-threads and with gcc on HPUX/ia64 passes test_types, but fails with some dynamic linking errors (__divdf3) in test_audioop. Looks like the bug is in the HP/UX compiler. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-30 18:53 Message: Logged In: YES user_id=29957 Python 2.3.2c1 (#2, Sep 30 2003, 04:35:11) [C] on hp-ux11 Type "help", "copyright", "credits" or "license" for more information. >>> import gc >>> z=range(12) >>> z.sort(2) >>> gc.collect() TypeError: 'int' object is not callable >>> ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-30 18:52 Message: Logged In: YES user_id=29957 wow. I exited python after the above z = range(12) z.sort(2) and got Exception exceptions.TypeError: "'int' object is not callable" in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection ABORT instruction (core dumped) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814976&group_id=5470 From noreply at sourceforge.net Wed Oct 1 03:03:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 03:03:31 2003 Subject: [Python-bugs-list] [ python-Bugs-812089 ] webbrowser.open_new() opens in an existing browser window Message-ID: Bugs item #812089, was opened at 2003-09-25 00:38 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812089&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Bram Cohen (bram_cohen) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.open_new() opens in an existing browser window Initial Comment: I'm running Windows with Mozilla (version 1.4) as my default web browser. When I call webbrowser.open_new() using Python 2.3 it opens the url in an existing window (if there are any) rather than opening a new one like it's supposed to. This might in some way be an interaction with tabbed browsing, since I always have a bunch of tabs open. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-09-26 14:37 Message: Logged In: YES user_id=11105 I can confirm (and possibly explain) everything that Bram reports. 1. The '-remote' switch on the command line for mozilla only works on Unix/Linux, as documented in http://www.mozilla.org/docs/command-line-args.html. So executing the command line "Program Files\mozilla.org\Mozilla\mozilla.exe" - remote "openURL(...)" doesn't load this url, it only starts mozilla. 2. webbrowser.py on Windows (for me at least) doesn't instantiate the Netscape class - it uses WindowsDefault, which simply uses startfile(url). So, the 'new' and 'autoraise' arguments are not even used. Looking at the docs for the webbrowser module, the words 'if possible' are used very often. So it seems, it simply is not possible on windows. (The only thing which should be fixed in the docs is that the win32api and win32con modules are mentioned, but they are not used in the code - so this should be removed IMO). I suggest to close the bug if noone comes up with a patch. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-09-26 13:39 Message: Logged In: YES user_id=11375 Looking at the code. this is what webbrowser.py should be doing. I can't debug this problem, because I'm not seeing it on my Linux box with Mozilla 1.4. I suggest you make a copy of webbrowser.py and insert debugging prints into it. Is it instantiating the Netscape class, as I expect? And what arguments is it really using? ---------------------------------------------------------------------- Comment By: Bram Cohen (bram_cohen) Date: 2003-09-26 03:34 Message: Logged In: YES user_id=52561 This is very bizzare. When I execute this command - C:\>"Program Files\mozilla.org\Mozilla\mozilla.exe" -remote "openURL(http://www.bitconjurer.org/, new-window)" it opens a new browser window with no page open in it. Are you sure it's executing the command you said? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-09-25 20:42 Message: Logged In: YES user_id=11375 It's invoking Mozilla with -remote "openURL(http://example.com, new-window)". According to http://www.mozilla.org/unix/remote.html, this should create a new window. Try to run this command yourself and set if it opens a new tab; if it does, this is a Mozilla bug (or perhaps a feature?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812089&group_id=5470 From noreply at sourceforge.net Wed Oct 1 03:03:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 03:03:34 2003 Subject: [Python-bugs-list] [ python-Bugs-815646 ] thread unsafe file objects cause crash Message-ID: Bugs item #815646, was opened at 2003-10-01 16:22 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815646&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jan Olderdissen (janixia) Assigned to: Nobody/Anonymous (nobody) Summary: thread unsafe file objects cause crash Initial Comment: Note: This may be a dupe or a generalization of 595601. Running below code snippet on 2.3.1 release and debug build on Windows 2000/XP a few times will inevitably lead to a crash. 2.2.2 also exhibits this behavior. The crashing code: ------------ import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f=open("tmp1", "w") f.seek (0, 0) thread.start_new_thread(worker, ()) thread.start_new_thread(worker, ()) while 1: pass ------------- The issue appears to be this (and similar) code sections from fileobject.c: Py_BEGIN_ALLOW_THREADS errno = 0; ret = _portable_fseek(f->f_fp, offset, whence); Py_END_ALLOW_THREADS Note that due to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS, f->f_fp can be set to NULL by file_close prior to entering _portable_fseek. Similar crashes can be observed with read, write and close itself when they are mixed with a concurrent close. Obviously, the offending python code is buggy and a lock should be used to prevent concurrent access to f. However, it seems unreasonable for Python to crash because of it. A mutex preventing concurrent access to the file object seems like a reasonable way to fix this. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:03 Message: Logged In: YES user_id=29957 Attaching the failing code as an attachment, because SF mangles source code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815646&group_id=5470 From noreply at sourceforge.net Wed Oct 1 03:08:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 03:08:48 2003 Subject: [Python-bugs-list] [ python-Bugs-815646 ] thread unsafe file objects cause crash Message-ID: Bugs item #815646, was opened at 2003-09-30 23:22 Message generated for change (Comment added) made by janixia You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815646&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jan Olderdissen (janixia) Assigned to: Nobody/Anonymous (nobody) Summary: thread unsafe file objects cause crash Initial Comment: Note: This may be a dupe or a generalization of 595601. Running below code snippet on 2.3.1 release and debug build on Windows 2000/XP a few times will inevitably lead to a crash. 2.2.2 also exhibits this behavior. The crashing code: ------------ import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f=open("tmp1", "w") f.seek (0, 0) thread.start_new_thread(worker, ()) thread.start_new_thread(worker, ()) while 1: pass ------------- The issue appears to be this (and similar) code sections from fileobject.c: Py_BEGIN_ALLOW_THREADS errno = 0; ret = _portable_fseek(f->f_fp, offset, whence); Py_END_ALLOW_THREADS Note that due to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS, f->f_fp can be set to NULL by file_close prior to entering _portable_fseek. Similar crashes can be observed with read, write and close itself when they are mixed with a concurrent close. Obviously, the offending python code is buggy and a lock should be used to prevent concurrent access to f. However, it seems unreasonable for Python to crash because of it. A mutex preventing concurrent access to the file object seems like a reasonable way to fix this. ---------------------------------------------------------------------- >Comment By: Jan Olderdissen (janixia) Date: 2003-10-01 00:08 Message: Logged In: YES user_id=877914 My apologies for the mangled source. I suppose there isn't a way for me to remedy the situation. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 00:03 Message: Logged In: YES user_id=29957 Attaching the failing code as an attachment, because SF mangles source code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815646&group_id=5470 From noreply at sourceforge.net Wed Oct 1 03:14:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 03:15:01 2003 Subject: [Python-bugs-list] [ python-Bugs-814976 ] test_types fails on HP/UX ia64 Message-ID: Bugs item #814976, was opened at 2003-09-30 18:51 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814976&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: test_types fails on HP/UX ia64 Initial Comment: 6. Built-in types 6.1 Truth value testing 6.2 Boolean operations 6.3 Comparisons 6.4 Numeric types (mostly conversions) 6.4.1 32-bit integers 6.4.2 Long integers 6.4.3 Floating point numbers 6.5 Sequence types 6.5.1 Strings 6.5.2 Tuples 6.5.3 Lists 6.5.3a Additional list operations Traceback (most recent call last): File "/house/arbatpy/Python-2.3.2c1/Lib/test/test_types.py", line 415, in ? else: raise TestFailed, 'list sort compare function is not callable' test.test_support.TestFailed: list sort compare function is not callable The test in question is definately failing: >>> z=range(12) >>> z.sort(2) >>> (it should raise a TypeError). Anyone? ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:14 Message: Logged In: YES user_id=29957 I've sent in a note to the feedback address on the HP site - I don't know if they're likely to respond or not. Ok, I blew everything away and started again with absolutely 100% no optimisation involved, and this time it worked!?! I was trying it on the "other" HP/ia64 box (there's two in the testdrive farm). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:00 Message: Logged In: YES user_id=29957 Linux/ia64 works fine. Building --without-threads and with gcc on HPUX/ia64 passes test_types, but fails with some dynamic linking errors (__divdf3) in test_audioop. Looks like the bug is in the HP/UX compiler. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-30 18:53 Message: Logged In: YES user_id=29957 Python 2.3.2c1 (#2, Sep 30 2003, 04:35:11) [C] on hp-ux11 Type "help", "copyright", "credits" or "license" for more information. >>> import gc >>> z=range(12) >>> z.sort(2) >>> gc.collect() TypeError: 'int' object is not callable >>> ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-30 18:52 Message: Logged In: YES user_id=29957 wow. I exited python after the above z = range(12) z.sort(2) and got Exception exceptions.TypeError: "'int' object is not callable" in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection ABORT instruction (core dumped) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814976&group_id=5470 From noreply at sourceforge.net Wed Oct 1 03:28:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 03:28:32 2003 Subject: [Python-bugs-list] [ python-Bugs-815668 ] test_locale and en_US Message-ID: Bugs item #815668, was opened at 2003-10-01 17: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=815668&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: test_locale and en_US Initial Comment: Is it worth making test_locale try first "en_US", then "C", as locale names? None of the systems I've tried have "en_US" as a valid locale. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815668&group_id=5470 From noreply at sourceforge.net Wed Oct 1 04:52:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 04:53:03 2003 Subject: [Python-bugs-list] [ python-Bugs-811028 ] configure: curses busted on Freebsd/Mac OSX Message-ID: Bugs item #811028, was opened at 2003-09-23 17:50 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: configure: curses busted on Freebsd/Mac OSX Initial Comment: Anthony said to log this: checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug- autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## I'll attach the text of the report and the configure output too since I'm pretty sure the above won't be ligible once sf's tracker's finished with it. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 18:52 Message: Logged In: YES user_id=29957 Unless a FreeBSD or Mac OS X expert can step forward in the next day and suggest a fix, this isn't going to be fixed for 2.3.2(final). I can't spend any more time on it. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-10-01 09:29 Message: Logged In: YES user_id=6405 The diagnosis on OS X is similar, and the trigger for defining wchar_t in stdlib.h is the absence of _ANSI_SOURCE. Making it not define _XOPEN_SOURCE_EXTENDED also fixes the compile as per your FreeBSD fix. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 00:24 Message: Logged In: YES user_id=29957 Looking into it a bit on FreeBSD: /usr/include/ncurses.h:236: conflicting types for `wchar_t' /usr/include/stdlib.h:58: previous declaration of `wchar_t' and poking around a bit I find that stdlib.h defines wchar_t as an 'int', while ncurses.h defines it as 'unsigned long'. This is on FreeBSD 4.8. Extracting the failing configure code and making it not define _XOPEN_EXTENDED_SOURCE makes the test succeed, but I have no idea if this is an appropriate fix. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-27 18:36 Message: Logged In: YES user_id=6405 (I didn't mention it in the report, only to Anthony : this is on OSX) The patch doesn't alter the configure behaviour. I can't remember how to run the curses test - "make test" skips it (the curses module is built though). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-27 17:53 Message: Logged In: YES user_id=21627 Can you try the patch in python.org/sf/806800 ? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-23 18:28 Message: Logged In: YES user_id=6405 "make test" also reports: test_curses test test_curses crashed -- _curses.error: curs_set() returned ERR ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-23 18:14 Message: Logged In: YES user_id=29957 creosote (which is a freebsd machine) also sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 From noreply at sourceforge.net Wed Oct 1 04:53:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 04:53:58 2003 Subject: [Python-bugs-list] [ python-Bugs-814976 ] test_types fails on HP/UX ia64 Message-ID: Bugs item #814976, was opened at 2003-09-30 18:51 Message generated for change (Settings changed) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814976&group_id=5470 Category: None Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: test_types fails on HP/UX ia64 Initial Comment: 6. Built-in types 6.1 Truth value testing 6.2 Boolean operations 6.3 Comparisons 6.4 Numeric types (mostly conversions) 6.4.1 32-bit integers 6.4.2 Long integers 6.4.3 Floating point numbers 6.5 Sequence types 6.5.1 Strings 6.5.2 Tuples 6.5.3 Lists 6.5.3a Additional list operations Traceback (most recent call last): File "/house/arbatpy/Python-2.3.2c1/Lib/test/test_types.py", line 415, in ? else: raise TestFailed, 'list sort compare function is not callable' test.test_support.TestFailed: list sort compare function is not callable The test in question is definately failing: >>> z=range(12) >>> z.sort(2) >>> (it should raise a TypeError). Anyone? ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 18:53 Message: Logged In: YES user_id=29957 Closing this now - it's a bug in the HP compiler. I've put a workaround in the HP/UX section of the toplevel README file. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:14 Message: Logged In: YES user_id=29957 I've sent in a note to the feedback address on the HP site - I don't know if they're likely to respond or not. Ok, I blew everything away and started again with absolutely 100% no optimisation involved, and this time it worked!?! I was trying it on the "other" HP/ia64 box (there's two in the testdrive farm). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:00 Message: Logged In: YES user_id=29957 Linux/ia64 works fine. Building --without-threads and with gcc on HPUX/ia64 passes test_types, but fails with some dynamic linking errors (__divdf3) in test_audioop. Looks like the bug is in the HP/UX compiler. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-30 18:53 Message: Logged In: YES user_id=29957 Python 2.3.2c1 (#2, Sep 30 2003, 04:35:11) [C] on hp-ux11 Type "help", "copyright", "credits" or "license" for more information. >>> import gc >>> z=range(12) >>> z.sort(2) >>> gc.collect() TypeError: 'int' object is not callable >>> ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-30 18:52 Message: Logged In: YES user_id=29957 wow. I exited python after the above z = range(12) z.sort(2) and got Exception exceptions.TypeError: "'int' object is not callable" in 'garbage collection' ignored Fatal Python error: unexpected exception during garbage collection ABORT instruction (core dumped) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814976&group_id=5470 From noreply at sourceforge.net Wed Oct 1 05:03:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 05:03:17 2003 Subject: [Python-bugs-list] [ python-Bugs-814613 ] socketmodule.c fails build, INET_ADDRSTRLEN not defined Message-ID: Bugs item #814613, was opened at 2003-09-30 04:22 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814613&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Randy Davis (randydavis1) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c fails build, INET_ADDRSTRLEN not defined Initial Comment: Modules/socketmodule.c fails to built on IRIX 6.3 gcc 3.2.2 due to INET_ADDRSTRLEN not being defined. Adding an additional "#define INET_ADDRSTRLEN 16" outside of the #ifdef's fixes it (so the #ifdefs would seem to not be taking into account IRIX 6.3). Here's the error: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes - shared -fno-strict-aliasing -I. - I/usr2/admin/src/dev/python-2.3.1/./Include - I/usr/local/include -I/usr2/admin/src/dev/python- 2.3.1/Include -I/usr2/admin/src/dev/python-2.3.1 - c /usr2/admin/src/dev/pyth on-2.3.1/Modules/socketmodule.c -o build/temp.irix-6.3- 2.3/socketmodule.o /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c: In function `socket_gethostname': /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:2319: warning: implicit declaration of function `gethostname' /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c: In function `socket_inet_ntop': /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: `INET_ADDRSTRLEN' undeclared (first use in this function) /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: (Each undeclared identifier is reported only once /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: for each function it appears in.) /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: warning: unused variable `ip' ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 19:03 Message: Logged In: YES user_id=29957 Hm. It looks we define INET_ADDRSTRLEN only if ENABLE_IPV6 is false. Looking on my Linux machine, if IPV6 is enabled, INET_ADDRSTRLEN is defined in netinet/in.h - can you see if it's available in any Irix header files? Alternately, try rerunning configure with --disable-ipv6. We could probably put an #ifndef INET_ADDRSTRLEN #define INET_ADDRSTRLEN 16 #endif in socketmodule.c, but this seems to me like the problem might be in the SGI headers... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814613&group_id=5470 From noreply at sourceforge.net Wed Oct 1 06:11:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 06:11:08 2003 Subject: [Python-bugs-list] [ python-Bugs-812376 ] Problem with ftplib on HP-UX11i Message-ID: Bugs item #812376, was opened at 2003-09-25 12:10 Message generated for change (Comment added) made by rptownsend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Townsend (rptownsend) Assigned to: Nobody/Anonymous (nobody) Summary: Problem with ftplib on HP-UX11i Initial Comment: The following code fails on Python 2.3 (and 2.3.1). import ftplib f = ftplib.FTP() f.connect('hostname', 21) this raises: socket.gaierror: (8, 'host nor service provided, or not known') In FTP.connect() it is the call to socket.getaddrinfo() that is raising the exception. The same code works OK on Python 2.2.1 If I pass an IP address instead of a hostname, the code runs OK on Python 2.3 ---------------------------------------------------------------------- >Comment By: Richard Townsend (rptownsend) Date: 2003-10-01 11:11 Message: Logged In: YES user_id=200117 I tried dropping different versions of socketmodule.c & socketmodule.h into Python-2.3.1 and re-building. The earliest version of socketmodule.c I could build & run was 1.219 and this does raise the exception for a hostname that needs to be resolved via NIS. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-30 15:48 Message: Logged In: YES user_id=29957 Darn. There's probably something Not Quite Right with how socketmodule.c interacts with HP/UX's NIS, then. I'm not sure what the problem would be, and I don't have access to a HP/UX box that uses NIS for hostnames, so I'm not able to help... As previously mentioned, there's a _lot_ of changes been made to socketmodule.c between 2.2 and 2.3. If you're CVS-savvy, you might like to try checking out different versions between 2.200 (the version in 2.2) and 2.270 (the version in 2.3) to narrow down exactly when the module stops working. One thing - "_" isn't supposed to be legal in domain names, I don't know if that's related (although the other name has no underscores...) ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-09-30 14:56 Message: Logged In: YES user_id=200117 The hostnames I have tried are 'tate_mod' and 'rosalind'. Lookup is by NIS. I can ping and remote login to these workstations using their hostnames. I have since discovered that if I add an entry to /etc/hosts specifying a different hostname 'fred' and rosalind's IP address, then f.connect('fred', 21) doesn't give the error. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-30 14:01 Message: Logged In: YES user_id=29957 Hm. What's the actual hostname you're trying? I can't get this failure on HP/UX 11.11, using the HP testdrive box. Are you using NIS or some other non-standard method of hostname lookup? The problem is that there's a fair bit changed between 2.2 and 2.3's socket module (there was 71 different checkins). ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-09-30 13:21 Message: Logged In: YES user_id=200117 Apologies for not being clear. I actually used the real hostname (in quotes) of a workstation on our local network in place of 'hostname'. If I use 'localhost' or the hostname of the workstation the application is running on, I don't get the error. If I use the hostname of any other workstation on the local network, I do get the error. Running exactly the same code on Python 2.2.1 works OK for all hostnames. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-30 10:44 Message: Logged In: YES user_id=29957 Using the HP testdrive system HP-UX spe169 B.11.11 U 9000/800 1939057856 unlimited-user license I did the following with 2.3.2c1: >>> import ftplib >>> f = ftplib.FTP() >>> f.connect('localhost', 21) '220 spe169.testdrive.hp.com FTP server (Version 1.1.214.4(PHNE_27765) Wed Sep 4 05:59:34 GMT 2002) ready.' >>> Ah. In your example, you have 'hostname'. Is that _literally_ what you typed? If so, it's looking for a machine called 'hostname'. I tried that, and got the same error you got. Try it without the single quotes around 'hostname'. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-26 18:50 Message: Logged In: YES user_id=29957 Hm. I'm obviously having reading difficulties. There's obviously something else going on entirely. Damn. I will try to grab some time on one of the HP test boxes to see if I can figure what's going on... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-26 18:49 Message: Logged In: YES user_id=29957 Did the workaround fix the problem? I'm not sure why it'd work for 2.3 and not 2.3.1, unless 2.3.1's script was generated with a newer version of autoconf - aha. Yes, it was. If you could check if the fix in https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470 "makes it all better", that would be great. Put aclocal.m4 alongside configure &c, re-run autoconf, then ./configure ; make ---------------------------------------------------------------------- Comment By: Richard Townsend (rptownsend) Date: 2003-09-26 18:21 Message: Logged In: YES user_id=200117 I had already applied the workaround to my 2.3.1 build. I don't think configure was broken with Python 2.3 - and it was with 2.3 that I first noticed the problem. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-26 18:04 Message: Logged In: YES user_id=29957 Hm. I wonder if this is related to the configure broken-ness. Can you apply the workaround from http://www.python.org/2.3.1/bugs.html and see if the problem is fixed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470 From noreply at sourceforge.net Wed Oct 1 06:31:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 06:31:14 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 12: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=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Nobody/Anonymous (nobody) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Wed Oct 1 10:43:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 10:43:49 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 20:31 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Nobody/Anonymous (nobody) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 00:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Wed Oct 1 10:44:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 10:45:13 2003 Subject: [Python-bugs-list] [ python-Bugs-814602 ] socket.gethostbyaddr('www.google.com') Message-ID: Bugs item #814602, was opened at 2003-09-30 04:09 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814602&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerd Schulz (spikeee) Assigned to: Nobody/Anonymous (nobody) Summary: socket.gethostbyaddr('www.google.com') Initial Comment: Results in error! ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 00:44 Message: Logged In: YES user_id=29957 What platform? What compiler? What exact version of Python? What was the error? Does the same code work under an earlier version of Python? If so, which version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814602&group_id=5470 From noreply at sourceforge.net Wed Oct 1 11:04:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 11:04:41 2003 Subject: [Python-bugs-list] [ python-Bugs-811028 ] configure: curses busted on Freebsd/Mac OSX Message-ID: Bugs item #811028, was opened at 2003-09-23 09:50 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: configure: curses busted on Freebsd/Mac OSX Initial Comment: Anthony said to log this: checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug- autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## I'll attach the text of the report and the configure output too since I'm pretty sure the above won't be ligible once sf's tracker's finished with it. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-10-01 17:04 Message: Logged In: YES user_id=45365 I've also seen this. I don't have the time to dive into this, but I think it has to do with gcc 3.3. I had just upgraded to gcc 3.3 from 3.1, and before the upgrade I never saw the problem. Is everyone who sees the problem using gcc 3.3, by any chance? If so then it's probably an incompatibility between curses.h and that compiler. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 10:52 Message: Logged In: YES user_id=29957 Unless a FreeBSD or Mac OS X expert can step forward in the next day and suggest a fix, this isn't going to be fixed for 2.3.2(final). I can't spend any more time on it. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-10-01 01:29 Message: Logged In: YES user_id=6405 The diagnosis on OS X is similar, and the trigger for defining wchar_t in stdlib.h is the absence of _ANSI_SOURCE. Making it not define _XOPEN_SOURCE_EXTENDED also fixes the compile as per your FreeBSD fix. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-30 16:24 Message: Logged In: YES user_id=29957 Looking into it a bit on FreeBSD: /usr/include/ncurses.h:236: conflicting types for `wchar_t' /usr/include/stdlib.h:58: previous declaration of `wchar_t' and poking around a bit I find that stdlib.h defines wchar_t as an 'int', while ncurses.h defines it as 'unsigned long'. This is on FreeBSD 4.8. Extracting the failing configure code and making it not define _XOPEN_EXTENDED_SOURCE makes the test succeed, but I have no idea if this is an appropriate fix. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-27 10:36 Message: Logged In: YES user_id=6405 (I didn't mention it in the report, only to Anthony : this is on OSX) The patch doesn't alter the configure behaviour. I can't remember how to run the curses test - "make test" skips it (the curses module is built though). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-27 09:53 Message: Logged In: YES user_id=21627 Can you try the patch in python.org/sf/806800 ? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-23 10:28 Message: Logged In: YES user_id=6405 "make test" also reports: test_curses test test_curses crashed -- _curses.error: curs_set() returned ERR ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-23 10:14 Message: Logged In: YES user_id=29957 creosote (which is a freebsd machine) also sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 From noreply at sourceforge.net Wed Oct 1 11:10:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 11:11:06 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 11:31 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Nobody/Anonymous (nobody) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-01 16:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 15:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Wed Oct 1 11:19:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 11:19:44 2003 Subject: [Python-bugs-list] [ python-Bugs-815924 ] tkMessageBox functions reject "type" and "icon" keywords Message-ID: Bugs item #815924, was opened at 2003-10-01 16: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=815924&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Tim Diggins (tdiggins) Assigned to: Martin v. L?wis (loewis) Summary: tkMessageBox functions reject "type" and "icon" keywords Initial Comment: Python 2.2.x -> Python 2.3 I've noticed a small separation between documentation and reality in tkMessageBox. According to Fredrik Lundh's documentation of tkMessageBox (in the various online guides & ?printed) you can send type and icon keywords to tkMessageBox's convenience functions (like askquestion) However this doesn't work. Don't know if it used to. So I'm not sure if the docs should be amended or amend the code (originally submitted by Fredrik). An attempt to clear up this bug but was rejected (I think, because they also added a feature). see BUG 761144 https://sourceforge.net/tracker/? func=detail&atid=105470&aid=761144&group_id=5470) A simple way to clean up this would be to amend the first three lines of _show as attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815924&group_id=5470 From noreply at sourceforge.net Wed Oct 1 11:34:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 11:34:55 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 20:31 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Nobody/Anonymous (nobody) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 01:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-02 01:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 00:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Wed Oct 1 11:45:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 11:45:20 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 12:31 Message generated for change (Comment added) made by eurosys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Nobody/Anonymous (nobody) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Roger Erens (eurosys) Date: 2003-10-01 17:45 Message: Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 17:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Wed Oct 1 11:51:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 11:51:24 2003 Subject: [Python-bugs-list] [ python-Bugs-814613 ] socketmodule.c fails build, INET_ADDRSTRLEN not defined Message-ID: Bugs item #814613, was opened at 2003-09-30 04:22 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814613&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Randy Davis (randydavis1) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c fails build, INET_ADDRSTRLEN not defined Initial Comment: Modules/socketmodule.c fails to built on IRIX 6.3 gcc 3.2.2 due to INET_ADDRSTRLEN not being defined. Adding an additional "#define INET_ADDRSTRLEN 16" outside of the #ifdef's fixes it (so the #ifdefs would seem to not be taking into account IRIX 6.3). Here's the error: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes - shared -fno-strict-aliasing -I. - I/usr2/admin/src/dev/python-2.3.1/./Include - I/usr/local/include -I/usr2/admin/src/dev/python- 2.3.1/Include -I/usr2/admin/src/dev/python-2.3.1 - c /usr2/admin/src/dev/pyth on-2.3.1/Modules/socketmodule.c -o build/temp.irix-6.3- 2.3/socketmodule.o /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c: In function `socket_gethostname': /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:2319: warning: implicit declaration of function `gethostname' /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c: In function `socket_inet_ntop': /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: `INET_ADDRSTRLEN' undeclared (first use in this function) /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: (Each undeclared identifier is reported only once /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: for each function it appears in.) /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: warning: unused variable `ip' ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 01:51 Message: Logged In: YES user_id=29957 With my brain screwed on correctly, I can see that my previous comments weren't correct. I'm attaching a (brutal) patch that "fixes" the problem, but before I apply it, I'd like to know if the problem is just with gcc on Irix, or does it also break with the SGI compiler? This looks like a gcc bug, maybe... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 19:03 Message: Logged In: YES user_id=29957 Hm. It looks we define INET_ADDRSTRLEN only if ENABLE_IPV6 is false. Looking on my Linux machine, if IPV6 is enabled, INET_ADDRSTRLEN is defined in netinet/in.h - can you see if it's available in any Irix header files? Alternately, try rerunning configure with --disable-ipv6. We could probably put an #ifndef INET_ADDRSTRLEN #define INET_ADDRSTRLEN 16 #endif in socketmodule.c, but this seems to me like the problem might be in the SGI headers... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814613&group_id=5470 From noreply at sourceforge.net Wed Oct 1 11:58:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 11:58:15 2003 Subject: [Python-bugs-list] [ python-Bugs-814544 ] AIX configure;make fails Message-ID: Bugs item #814544, was opened at 2003-09-30 02:27 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814544&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Ruttenberg (rutt) Assigned to: Nobody/Anonymous (nobody) Summary: AIX configure;make fails Initial Comment: Standard ./configure and make fails for me with both 2.2.3 and 2.3.1 on AIX. On AIX-5.1 with IBM's visualage compiler installed the build fails with the following: ./Modules/ld_so_aix cc_r -bI:Modules/python.exp build/temp.aix-5.1-2.2/cryptmodule.o -L/usr/local/lib -lcrypt -o \ build/lib.aix-5.1-2.2/crypt.so building '_socket' extension cc_r -DNDEBUG -O -DUSE_SSL=1 -I/usr/local/ssl/include -I. -I/home/rutt/src/Python-2.2.3/./Include -I/usr/local/in\ clude -I/home/rutt/src/Python-2.2.3/Include -I/home/rutt/src/Python-2.2.3 -c /home/rutt/src/Python-2.2.3/Modules/\ socketmodule.c -o build/temp.aix-5.1-2.2/socketmodule.o ./Modules/ld_so_aix cc_r -bI:Modules/python.exp build/temp.aix-5.1-2.2/socketmodule.o -L/usr/local/ssl/lib -L/usr\ /local/lib -lssl -lcrypto -o build/lib.aix-5.1-2.2/_socket.so ld: 0711-317 ERROR: Undefined symbol: .__umoddi3 ld: 0711-317 ERROR: Undefined symbol: .__udivdi3 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. *** WARNING: renaming "_socket" since importing it failed: from module build/lib.aix-5.1-2.2/_socket.so No such f\ ile or directory error: No such file or directory make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 01:58 Message: Logged In: YES user_id=29957 Hm. Could it be that socketmodule needs to be linked with libm on this platform? If you try the link stage of the code by hand, and add -lm after -lcrypto, does it help? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814544&group_id=5470 From noreply at sourceforge.net Wed Oct 1 12:08:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 12:08:24 2003 Subject: [Python-bugs-list] [ python-Bugs-814544 ] AIX configure;make fails Message-ID: Bugs item #814544, was opened at 2003-09-30 02:27 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814544&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: John Ruttenberg (rutt) Assigned to: Nobody/Anonymous (nobody) Summary: AIX configure;make fails Initial Comment: Standard ./configure and make fails for me with both 2.2.3 and 2.3.1 on AIX. On AIX-5.1 with IBM's visualage compiler installed the build fails with the following: ./Modules/ld_so_aix cc_r -bI:Modules/python.exp build/temp.aix-5.1-2.2/cryptmodule.o -L/usr/local/lib -lcrypt -o \ build/lib.aix-5.1-2.2/crypt.so building '_socket' extension cc_r -DNDEBUG -O -DUSE_SSL=1 -I/usr/local/ssl/include -I. -I/home/rutt/src/Python-2.2.3/./Include -I/usr/local/in\ clude -I/home/rutt/src/Python-2.2.3/Include -I/home/rutt/src/Python-2.2.3 -c /home/rutt/src/Python-2.2.3/Modules/\ socketmodule.c -o build/temp.aix-5.1-2.2/socketmodule.o ./Modules/ld_so_aix cc_r -bI:Modules/python.exp build/temp.aix-5.1-2.2/socketmodule.o -L/usr/local/ssl/lib -L/usr\ /local/lib -lssl -lcrypto -o build/lib.aix-5.1-2.2/_socket.so ld: 0711-317 ERROR: Undefined symbol: .__umoddi3 ld: 0711-317 ERROR: Undefined symbol: .__udivdi3 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. *** WARNING: renaming "_socket" since importing it failed: from module build/lib.aix-5.1-2.2/_socket.so No such f\ ile or directory error: No such file or directory make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 02:08 Message: Logged In: YES user_id=29957 Aha! Those missing symbols are from libgcc.a. So, it looks like the SSL libraries in /usr/local/lib were built with gcc, while you're trying to link them with the IBM compiler. A couple of approaches you could try: Build both Python and the OpenSSL libraries with the same compiler (either GCC or IBM's) Try adding -lgcc (plus the appropriate -L line to where-ever gcc has stashed it - usually somewhere like /usr/local/lib/gcc-lib//version/) to the end of the link line for socketmodule.so ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 01:58 Message: Logged In: YES user_id=29957 Hm. Could it be that socketmodule needs to be linked with libm on this platform? If you try the link stage of the code by hand, and add -lm after -lcrypto, does it help? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814544&group_id=5470 From noreply at sourceforge.net Wed Oct 1 12:28:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 12:28:52 2003 Subject: [Python-bugs-list] [ python-Bugs-811028 ] configure: curses busted on Freebsd/Mac OSX Message-ID: Bugs item #811028, was opened at 2003-09-23 17:50 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: configure: curses busted on Freebsd/Mac OSX Initial Comment: Anthony said to log this: checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug- autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## I'll attach the text of the report and the configure output too since I'm pretty sure the above won't be ligible once sf's tracker's finished with it. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 02:28 Message: Logged In: YES user_id=29957 Benno tells me that there's a patch for configure available at http://jeamland.net/~benno/configure.in.diff It'll fix FreeBSD, but not Mac OS X. Argh. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-10-02 01:04 Message: Logged In: YES user_id=45365 I've also seen this. I don't have the time to dive into this, but I think it has to do with gcc 3.3. I had just upgraded to gcc 3.3 from 3.1, and before the upgrade I never saw the problem. Is everyone who sees the problem using gcc 3.3, by any chance? If so then it's probably an incompatibility between curses.h and that compiler. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 18:52 Message: Logged In: YES user_id=29957 Unless a FreeBSD or Mac OS X expert can step forward in the next day and suggest a fix, this isn't going to be fixed for 2.3.2(final). I can't spend any more time on it. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-10-01 09:29 Message: Logged In: YES user_id=6405 The diagnosis on OS X is similar, and the trigger for defining wchar_t in stdlib.h is the absence of _ANSI_SOURCE. Making it not define _XOPEN_SOURCE_EXTENDED also fixes the compile as per your FreeBSD fix. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 00:24 Message: Logged In: YES user_id=29957 Looking into it a bit on FreeBSD: /usr/include/ncurses.h:236: conflicting types for `wchar_t' /usr/include/stdlib.h:58: previous declaration of `wchar_t' and poking around a bit I find that stdlib.h defines wchar_t as an 'int', while ncurses.h defines it as 'unsigned long'. This is on FreeBSD 4.8. Extracting the failing configure code and making it not define _XOPEN_EXTENDED_SOURCE makes the test succeed, but I have no idea if this is an appropriate fix. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-27 18:36 Message: Logged In: YES user_id=6405 (I didn't mention it in the report, only to Anthony : this is on OSX) The patch doesn't alter the configure behaviour. I can't remember how to run the curses test - "make test" skips it (the curses module is built though). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-27 17:53 Message: Logged In: YES user_id=21627 Can you try the patch in python.org/sf/806800 ? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-23 18:28 Message: Logged In: YES user_id=6405 "make test" also reports: test_curses test test_curses crashed -- _curses.error: curs_set() returned ERR ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-23 18:14 Message: Logged In: YES user_id=29957 creosote (which is a freebsd machine) also sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 From noreply at sourceforge.net Wed Oct 1 12:42:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 12:42:45 2003 Subject: [Python-bugs-list] [ python-Bugs-811028 ] configure: curses busted on Freebsd/Mac OSX Message-ID: Bugs item #811028, was opened at 2003-09-23 17:50 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: configure: curses busted on Freebsd/Mac OSX Initial Comment: Anthony said to log this: checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug- autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## I'll attach the text of the report and the configure output too since I'm pretty sure the above won't be ligible once sf's tracker's finished with it. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 02:42 Message: Logged In: YES user_id=29957 Ok. Ripping out the line AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, Define to activate Unix95-and-earlier features) from configure.in fixes the problem on FreeBSD. The only occurance of _XOPEN_SOURCE_EXTENDED in FreeBSD's headers is ncurses.h. FreeBSD will hopefully fix the bug in their headers to remove the problem in a future version of the code. Jack or Richard, can you see if _XOPEN_SOURCE_EXTENDED is used anywhere else on Mac OS X? If not, we could put a workaround in for Mac OS X and FreeBSD to not define the header. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 02:28 Message: Logged In: YES user_id=29957 Benno tells me that there's a patch for configure available at http://jeamland.net/~benno/configure.in.diff It'll fix FreeBSD, but not Mac OS X. Argh. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-10-02 01:04 Message: Logged In: YES user_id=45365 I've also seen this. I don't have the time to dive into this, but I think it has to do with gcc 3.3. I had just upgraded to gcc 3.3 from 3.1, and before the upgrade I never saw the problem. Is everyone who sees the problem using gcc 3.3, by any chance? If so then it's probably an incompatibility between curses.h and that compiler. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 18:52 Message: Logged In: YES user_id=29957 Unless a FreeBSD or Mac OS X expert can step forward in the next day and suggest a fix, this isn't going to be fixed for 2.3.2(final). I can't spend any more time on it. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-10-01 09:29 Message: Logged In: YES user_id=6405 The diagnosis on OS X is similar, and the trigger for defining wchar_t in stdlib.h is the absence of _ANSI_SOURCE. Making it not define _XOPEN_SOURCE_EXTENDED also fixes the compile as per your FreeBSD fix. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 00:24 Message: Logged In: YES user_id=29957 Looking into it a bit on FreeBSD: /usr/include/ncurses.h:236: conflicting types for `wchar_t' /usr/include/stdlib.h:58: previous declaration of `wchar_t' and poking around a bit I find that stdlib.h defines wchar_t as an 'int', while ncurses.h defines it as 'unsigned long'. This is on FreeBSD 4.8. Extracting the failing configure code and making it not define _XOPEN_EXTENDED_SOURCE makes the test succeed, but I have no idea if this is an appropriate fix. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-27 18:36 Message: Logged In: YES user_id=6405 (I didn't mention it in the report, only to Anthony : this is on OSX) The patch doesn't alter the configure behaviour. I can't remember how to run the curses test - "make test" skips it (the curses module is built though). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-27 17:53 Message: Logged In: YES user_id=21627 Can you try the patch in python.org/sf/806800 ? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-23 18:28 Message: Logged In: YES user_id=6405 "make test" also reports: test_curses test test_curses crashed -- _curses.error: curs_set() returned ERR ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-23 18:14 Message: Logged In: YES user_id=29957 creosote (which is a freebsd machine) also sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 From noreply at sourceforge.net Wed Oct 1 12:59:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 12:59:23 2003 Subject: [Python-bugs-list] [ python-Bugs-811028 ] configure: curses busted on Freebsd/Mac OSX Message-ID: Bugs item #811028, was opened at 2003-09-23 17:50 Message generated for change (Comment added) made by benno You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: configure: curses busted on Freebsd/Mac OSX Initial Comment: Anthony said to log this: checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug- autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## I'll attach the text of the report and the configure output too since I'm pretty sure the above won't be ligible once sf's tracker's finished with it. ---------------------------------------------------------------------- Comment By: Benno Rice (benno) Date: 2003-10-02 02:59 Message: Logged In: YES user_id=9925 There is a bug in FreeBSD's ncurses.h where it checks to see if a macro called __wchar_t is defined before attempting to typedef it's own wchar_t. This causes problems because __wchar_t (and wchar_t) exist, but __wchar_t is a typedef not a macro. This is solved by removing _XOPEN_SOURCE_EXTENDED which is what triggers this check. Removing _XOPEN_SOURCE_EXTENDED should have no other implications on FreeBSD. There is a patch that disables _XOPEN_SOURCE_EXTENDED for FreeBSD at http://jeamland.net/~benno/configure.in.diff ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 02:42 Message: Logged In: YES user_id=29957 Ok. Ripping out the line AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, Define to activate Unix95-and-earlier features) from configure.in fixes the problem on FreeBSD. The only occurance of _XOPEN_SOURCE_EXTENDED in FreeBSD's headers is ncurses.h. FreeBSD will hopefully fix the bug in their headers to remove the problem in a future version of the code. Jack or Richard, can you see if _XOPEN_SOURCE_EXTENDED is used anywhere else on Mac OS X? If not, we could put a workaround in for Mac OS X and FreeBSD to not define the header. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 02:28 Message: Logged In: YES user_id=29957 Benno tells me that there's a patch for configure available at http://jeamland.net/~benno/configure.in.diff It'll fix FreeBSD, but not Mac OS X. Argh. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-10-02 01:04 Message: Logged In: YES user_id=45365 I've also seen this. I don't have the time to dive into this, but I think it has to do with gcc 3.3. I had just upgraded to gcc 3.3 from 3.1, and before the upgrade I never saw the problem. Is everyone who sees the problem using gcc 3.3, by any chance? If so then it's probably an incompatibility between curses.h and that compiler. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 18:52 Message: Logged In: YES user_id=29957 Unless a FreeBSD or Mac OS X expert can step forward in the next day and suggest a fix, this isn't going to be fixed for 2.3.2(final). I can't spend any more time on it. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-10-01 09:29 Message: Logged In: YES user_id=6405 The diagnosis on OS X is similar, and the trigger for defining wchar_t in stdlib.h is the absence of _ANSI_SOURCE. Making it not define _XOPEN_SOURCE_EXTENDED also fixes the compile as per your FreeBSD fix. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 00:24 Message: Logged In: YES user_id=29957 Looking into it a bit on FreeBSD: /usr/include/ncurses.h:236: conflicting types for `wchar_t' /usr/include/stdlib.h:58: previous declaration of `wchar_t' and poking around a bit I find that stdlib.h defines wchar_t as an 'int', while ncurses.h defines it as 'unsigned long'. This is on FreeBSD 4.8. Extracting the failing configure code and making it not define _XOPEN_EXTENDED_SOURCE makes the test succeed, but I have no idea if this is an appropriate fix. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-27 18:36 Message: Logged In: YES user_id=6405 (I didn't mention it in the report, only to Anthony : this is on OSX) The patch doesn't alter the configure behaviour. I can't remember how to run the curses test - "make test" skips it (the curses module is built though). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-27 17:53 Message: Logged In: YES user_id=21627 Can you try the patch in python.org/sf/806800 ? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-23 18:28 Message: Logged In: YES user_id=6405 "make test" also reports: test_curses test test_curses crashed -- _curses.error: curs_set() returned ERR ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-23 18:14 Message: Logged In: YES user_id=29957 creosote (which is a freebsd machine) also sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 From noreply at sourceforge.net Wed Oct 1 12:19:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 13:01:37 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 11:31 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Nobody/Anonymous (nobody) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-01 17:19 Message: Logged In: YES user_id=6656 Can you attach the config.log for 2.2.3? I'm now a little curious as to how dynamic linking ever worked on this system (which is fairly old, right?) ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-01 16:45 Message: Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 16:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 15:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Wed Oct 1 13:21:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 13:21:29 2003 Subject: [Python-bugs-list] [ python-Bugs-815999 ] ImportError: No module named _socket Message-ID: Bugs item #815999, was opened at 2003-10-01 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=815999&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peter Stauffert (stauffert) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named _socket Initial Comment: Hi There is a problem during the installation of python 2.3.1: I used configure with the following options: ./configure --enable-shared=yes --with-signal- module=yes --with-cxx=/usr/freeware/bin/c++ make runs to the end, only warning messages are displayed. Running "make test" on a SGI Origin200, IRIX 6.5-18 I got the following error message: test test___all__ failed -- Traceback (most recent call last): File "/install/fw/Python-2.3.1/Lib/test/test___all__.py", line 54, in test_all import _socket ImportError: No module named _socket This looks like the python bug 565710 reported for python 2.2.1 which was solved by modifications of setup.py in the top level directory. But setup.py was modified in python 2.3.1 and I could not apply the old patch to the new version. Could you help me with this problem? Thanks a lot Peter Stauffert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 From noreply at sourceforge.net Wed Oct 1 15:44:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 15:44:28 2003 Subject: [Python-bugs-list] [ python-Bugs-814613 ] socketmodule.c fails build, INET_ADDRSTRLEN not defined Message-ID: Bugs item #814613, was opened at 2003-09-29 11:22 Message generated for change (Comment added) made by randydavis1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814613&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Randy Davis (randydavis1) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c fails build, INET_ADDRSTRLEN not defined Initial Comment: Modules/socketmodule.c fails to built on IRIX 6.3 gcc 3.2.2 due to INET_ADDRSTRLEN not being defined. Adding an additional "#define INET_ADDRSTRLEN 16" outside of the #ifdef's fixes it (so the #ifdefs would seem to not be taking into account IRIX 6.3). Here's the error: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes - shared -fno-strict-aliasing -I. - I/usr2/admin/src/dev/python-2.3.1/./Include - I/usr/local/include -I/usr2/admin/src/dev/python- 2.3.1/Include -I/usr2/admin/src/dev/python-2.3.1 - c /usr2/admin/src/dev/pyth on-2.3.1/Modules/socketmodule.c -o build/temp.irix-6.3- 2.3/socketmodule.o /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c: In function `socket_gethostname': /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:2319: warning: implicit declaration of function `gethostname' /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c: In function `socket_inet_ntop': /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: `INET_ADDRSTRLEN' undeclared (first use in this function) /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: (Each undeclared identifier is reported only once /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: for each function it appears in.) /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: warning: unused variable `ip' ---------------------------------------------------------------------- >Comment By: Randy Davis (randydavis1) Date: 2003-10-01 12:44 Message: Logged In: YES user_id=876412 Testing for INET_ADDRSTRLEN defined in the header files: ----- $ find /usr/include /usr/local/include -type f -exec INET_ADDRSTRLEN {} /dev/null \; $ ----- Nope, INET_ADDRSTRLEN isn't defined anywhere under IRIX 6.3, nor in any of the gcc (etc) installed header files under /usr/local/include. (Thus, configuring with --disable- ipv6 didn't help, either). Concerning whether the SGI compiler does it also, I don't know - the SGI compiler is a licensed product and isn't licensed on this system (hence the use of gcc - but, gcc has successfully compiled over 44 open source packages so far, including samba and other network-related applications). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 08:51 Message: Logged In: YES user_id=29957 With my brain screwed on correctly, I can see that my previous comments weren't correct. I'm attaching a (brutal) patch that "fixes" the problem, but before I apply it, I'd like to know if the problem is just with gcc on Irix, or does it also break with the SGI compiler? This looks like a gcc bug, maybe... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 02:03 Message: Logged In: YES user_id=29957 Hm. It looks we define INET_ADDRSTRLEN only if ENABLE_IPV6 is false. Looking on my Linux machine, if IPV6 is enabled, INET_ADDRSTRLEN is defined in netinet/in.h - can you see if it's available in any Irix header files? Alternately, try rerunning configure with --disable-ipv6. We could probably put an #ifndef INET_ADDRSTRLEN #define INET_ADDRSTRLEN 16 #endif in socketmodule.c, but this seems to me like the problem might be in the SGI headers... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814613&group_id=5470 From noreply at sourceforge.net Wed Oct 1 15:53:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 15:54:06 2003 Subject: [Python-bugs-list] [ python-Bugs-815999 ] ImportError: No module named _socket Message-ID: Bugs item #815999, was opened at 2003-10-01 10:21 Message generated for change (Comment added) made by caseyd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peter Stauffert (stauffert) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named _socket Initial Comment: Hi There is a problem during the installation of python 2.3.1: I used configure with the following options: ./configure --enable-shared=yes --with-signal- module=yes --with-cxx=/usr/freeware/bin/c++ make runs to the end, only warning messages are displayed. Running "make test" on a SGI Origin200, IRIX 6.5-18 I got the following error message: test test___all__ failed -- Traceback (most recent call last): File "/install/fw/Python-2.3.1/Lib/test/test___all__.py", line 54, in test_all import _socket ImportError: No module named _socket This looks like the python bug 565710 reported for python 2.2.1 which was solved by modifications of setup.py in the top level directory. But setup.py was modified in python 2.3.1 and I could not apply the old patch to the new version. Could you help me with this problem? Thanks a lot Peter Stauffert ---------------------------------------------------------------------- Comment By: casey dunn (caseyd) Date: 2003-10-01 12:53 Message: Logged In: YES user_id=878394 I have seen this on Solaris as well, recent and old vintages. Casey Dunn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 From noreply at sourceforge.net Wed Oct 1 14:51:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 16:01:48 2003 Subject: [Python-bugs-list] [ python-Bugs-768649 ] popen4 doesn't close filedescriptors when in Threads Message-ID: Bugs item #768649, was opened at 2003-07-09 13:36 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768649&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: martin doudoroff (mdoudoroff) Assigned to: Nobody/Anonymous (nobody) Summary: popen4 doesn't close filedescriptors when in Threads Initial Comment: Running the following code under Linux will result in a crash on the 508th thread started. The error is OSError: [Errno 24] Too many open files The nature of the bug seems to be that Python isn't closing filedescriptors cleanly when running a thread. --------------------------------------- import os from threading import Thread class Crash(Thread): def run(self): a = os.popen4('ls') b = a[1].read() # uncommenting these lines fixes the problem # but this isn't really documented as far as # we can tell... # a[0].close() # a[1].close() for i in range(1000): t = Crash() t.start() while t.isAlive(): pass print i --------------------------------------- The same code without threads (Crash as a plain class) doesn't crash, so the descriptor must be getting taken care of when the run() method is exited. import os class Crash: def run(self): a = os.popen4('ls') b = a[1].read() for i in range(1000): t = Crash() t.run() print i ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-01 13:51 Message: Logged In: YES user_id=139865 Duplicated with Python 2.3 on Red Hat 7.3 using glibc-2.2.5-43. Popen3.{poll,wait} are written under the incorrect assumption that waitpid can monitor any process in the same process group, when it only works for immediate children. _active.remove is never called, so Popen3 objects are never destroyed and the associated file descriptors are not returned to the operating system. A general solution for Popen[34] is not obvious to me. With patch #816059, popen2.popen[234] plugs the _active leak, which in turn returns the file descriptors to the operating system when the file objects that popen2.popen[234] return go out of scope. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-09 22:20 Message: Logged In: YES user_id=33168 I can't duplicate this on Redhat 9. What OS, what version of glibc and what kernel are you using? Does it always crash on the 508th iteration? I tested with both 2.2.3 and 2.3b2 from CVS without problems. I even used ulimit to set my open files to 10. Can you try the patch in bug #761888 to see if that helps? http://pythong.org/sf/761888 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768649&group_id=5470 From noreply at sourceforge.net Wed Oct 1 14:50:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 16:02:14 2003 Subject: [Python-bugs-list] [ python-Bugs-761888 ] popen2.Popen3 and popen2.Popen4 leaks filedescriptors Message-ID: Bugs item #761888, was opened at 2003-06-27 09:58 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761888&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Troels Walsted Hansen (troels) Assigned to: Neal Norwitz (nnorwitz) Summary: popen2.Popen3 and popen2.Popen4 leaks filedescriptors Initial Comment: The code below (from Lib/popen2.py) appears to leak no less then 4 filedescriptors if os.fork() raises an exception (say "OSError: [Errno 12] Not enough space" on a Solaris box running out of swap). Popen3.__init__() appears to leak 6 filedescriptors. class Popen4(Popen3): def __init__(self, cmd, bufsize=-1): p2cread, p2cwrite = os.pipe() c2pread, c2pwrite = os.pipe() self.pid = os.fork() ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-01 13:50 Message: Logged In: YES user_id=139865 Patch #816059 includes a less ugly fix for this bug. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-10 11:30 Message: Logged In: YES user_id=6656 "new patch 3" looks ok, ish. wouldn't the last try block be better written as try: os.fork() execpt OSError: cleanup raise else: ... ? It's possible I'm missing something, of course. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-09 11:39 Message: Logged In: YES user_id=6380 The fd-as-object idea has dangers too: there may be situations where you might be passing a fd to some extension code and never use it again yourself -- but losing the fd would close it! Not a good thing. (The simples example of this would be os.close() itself. :-) I don't think I can review the patch adequately; as it is quite complex I recommend that you check it in and the point python-dev and c.l.py.ann to it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 22:40 Message: Logged In: YES user_id=33168 I tried to make it easier to review the patches by providing 2. They were wrong though. It was still possible to leak file descriptors. I believe the new patch 3 should not allow any file descriptors to leak. This solution is really ugly, but I can't come up with anything cleaner. I tried having a list of the fds that need to be closed, but it really isn't any better. Would it be possible (in 2.4) to make an fd type which derives from int, so that the fd can be closed on deallocation? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 10:57 Message: Logged In: YES user_id=6380 I haven't reviewed the code or the fix, but as a bugfix this could go into 2.3. The two patch files are confusing -- why two? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-28 22:10 Message: Logged In: YES user_id=33168 Tim, for 2.3b2 or 2.3.1? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-28 22:09 Message: Logged In: YES user_id=33168 The attached patch should fix the problem, I'd appreciate if you could test this. There are 2 files attached, one is a context diff with whitespace modifications, the other is a minimal (no whitespace differences) patch to show what's changed (ie, the try/except). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761888&group_id=5470 From noreply at sourceforge.net Wed Oct 1 21:17:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 1 21:17:39 2003 Subject: [Python-bugs-list] [ python-Bugs-811898 ] int ("ffffffd3", 16) gives error Message-ID: Bugs item #811898, was opened at 2003-09-24 11:44 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811898&group_id=5470 Category: None Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Neal D. Becker (nbecker) Assigned to: Nobody/Anonymous (nobody) Summary: int ("ffffffd3", 16) gives error Initial Comment: Subject says it all. This should not give an error on a machine that uses 32-bit 2's complement representation for int. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-01 20:17 Message: Logged In: YES user_id=139865 ints in Python 2.2 on a 32 bit machine can only hold values from -(2 ** 31) to (2 ** 31) - 1. int() will not return a negative number without a minus sign, the opposite of what hex literals do. In Python 2.3, int('ffffffd3', 16) returns 4294967251L. In Python 2.4, 0xffffffd3 will mean 4294967251L. See PEP 237 for more information. Mark as invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811898&group_id=5470 From noreply at sourceforge.net Thu Oct 2 01:05:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 01:05:52 2003 Subject: [Python-bugs-list] [ python-Bugs-816344 ] Missing import in email example Message-ID: Bugs item #816344, was opened at 2003-10-02 17: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=816344&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Missing import in email example Initial Comment: The "email-dir.py" example in the email module documentation is missing an import. The MIMEBase is used (when a generic file is found), but MIMEBase is not imported. Putting "from email.MIMEBase import MIMEBase" with the other imports fixes this. This is Python 2.3.1, and also the cvs that anon sf thinks is current. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816344&group_id=5470 From noreply at sourceforge.net Thu Oct 2 06:42:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 06:43:00 2003 Subject: [Python-bugs-list] [ python-Bugs-816476 ] Fatal Python error: GC object already tracked Message-ID: Bugs item #816476, was opened at 2003-10-02 10: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=816476&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thorsten Henninger (thenninger) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python error: GC object already tracked Initial Comment: Fatal Python error: GC object already tracked OS: Windows 2000 Server (Service Pack 4) Python: 2.3.1 (#47) pycurl: 7.10.6 I got this Fatal Error while fetching Webpages with pycurl. I do not have any other addiotional information. This error is reproducible and did not occur with Python2.2. Please contact me, if you need further information ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 From noreply at sourceforge.net Thu Oct 2 06:51:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 06:51:54 2003 Subject: [Python-bugs-list] [ python-Bugs-816476 ] Fatal Python error: GC object already tracked Message-ID: Bugs item #816476, was opened at 2003-10-02 11:42 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thorsten Henninger (thenninger) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python error: GC object already tracked Initial Comment: Fatal Python error: GC object already tracked OS: Windows 2000 Server (Service Pack 4) Python: 2.3.1 (#47) pycurl: 7.10.6 I got this Fatal Error while fetching Webpages with pycurl. I do not have any other addiotional information. This error is reproducible and did not occur with Python2.2. Please contact me, if you need further information ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-02 11:51 Message: Logged In: YES user_id=6656 Why do you think this is a bug in Python and not pycurl? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 From noreply at sourceforge.net Thu Oct 2 11:54:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 11:54:49 2003 Subject: [Python-bugs-list] [ python-Bugs-816627 ] file read() forgets some bytes Message-ID: Bugs item #816627, was opened at 2003-10-02 17: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=816627&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: file read() forgets some bytes Initial Comment: It seems the python miscalculates the size of a file. This is on windows, with python 2.2.2 from ActiveState E:\work\jayacard\inkit\demo>python ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array, os >>> fname = "current_img.jpg" >>> print len(open(fname).read()) 41 >>> print os.stat(fname).st_size 693 As you can see, there some mismatch here. 693 is indeed the size reported by the windows explorer. >>> a = array.array('B') >>> a.fromfile( open(fname), 693) Traceback (most recent call last): File "", line 1, in ? EOFError: not enough items in file >>> a.fromfile(open(fname), 42) Traceback (most recent call last): File "", line 1, in ? EOFError: not enough items in file >>> a.fromfile(open(fname), 41) >>> a = array.array('B') >>> a.fromfile(open(fname), 41) >>> len(a) 41 I attach the nasty file This is a very serious bug for me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816627&group_id=5470 From noreply at sourceforge.net Thu Oct 2 11:55:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 11:55:58 2003 Subject: [Python-bugs-list] [ python-Feature Requests-816628 ] request for bugs.python.org Message-ID: Feature Requests item #816628, was opened at 2003-10-02 17:55 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=816628&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: request for bugs.python.org Initial Comment: Many projects (gentoo, gnome, kde...) have the conveninent url for accessing the bug database: bugs.python.org That would be cool. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 From noreply at sourceforge.net Thu Oct 2 12:02:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 12:02:13 2003 Subject: [Python-bugs-list] [ python-Bugs-816627 ] file read() forgets some bytes Message-ID: Bugs item #816627, was opened at 2003-10-02 11: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=816627&group_id=5470 Category: Python Library >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: file read() forgets some bytes Initial Comment: It seems the python miscalculates the size of a file. This is on windows, with python 2.2.2 from ActiveState E:\work\jayacard\inkit\demo>python ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array, os >>> fname = "current_img.jpg" >>> print len(open(fname).read()) 41 >>> print os.stat(fname).st_size 693 As you can see, there some mismatch here. 693 is indeed the size reported by the windows explorer. >>> a = array.array('B') >>> a.fromfile( open(fname), 693) Traceback (most recent call last): File "", line 1, in ? EOFError: not enough items in file >>> a.fromfile(open(fname), 42) Traceback (most recent call last): File "", line 1, in ? EOFError: not enough items in file >>> a.fromfile(open(fname), 41) >>> a = array.array('B') >>> a.fromfile(open(fname), 41) >>> len(a) 41 I attach the nasty file This is a very serious bug for me. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-02 12:02 Message: Logged In: YES user_id=31435 Windows makes a distinction between binary-mode and text- mode files. open() defaults to text-mode. A .jpg is certainly a binary file, so on Windows you *must* open with it in binary mode. That means changing your open(fname) to open(fname, 'rb') Your problem will go away then. It's unfortunate, but that's the way Windows works -- it's not a Python bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816627&group_id=5470 From noreply at sourceforge.net Thu Oct 2 12:15:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 12:15:11 2003 Subject: [Python-bugs-list] [ python-Feature Requests-816628 ] request for bugs.python.org Message-ID: Feature Requests item #816628, was opened at 2003-10-02 11:55 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 Category: Documentation Group: None Status: Open >Resolution: Later Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: request for bugs.python.org Initial Comment: Many projects (gentoo, gnome, kde...) have the conveninent url for accessing the bug database: bugs.python.org That would be cool. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-10-02 12:15 Message: Logged In: YES user_id=12800 Even if it's a good idea, we can't do this until the PSF controls the python.org domain. I don't know what the status of that is, but I believe a transfer is in the works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=816628&group_id=5470 From noreply at sourceforge.net Thu Oct 2 12:25:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 12:25:43 2003 Subject: [Python-bugs-list] [ python-Bugs-816476 ] Fatal Python error: GC object already tracked Message-ID: Bugs item #816476, was opened at 2003-10-02 06:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thorsten Henninger (thenninger) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python error: GC object already tracked Initial Comment: Fatal Python error: GC object already tracked OS: Windows 2000 Server (Service Pack 4) Python: 2.3.1 (#47) pycurl: 7.10.6 I got this Fatal Error while fetching Webpages with pycurl. I do not have any other addiotional information. This error is reproducible and did not occur with Python2.2. Please contact me, if you need further information ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-02 12:25 Message: Logged In: YES user_id=31435 You should report this to the pycurl project. The specific error message you report is new in Python 2.3, doing a check for errnoneous usage of the Python C API. That check didn't exist in Python 2.2. While it's possible there's a previously unreported error in Python 2.3 here, it's much more likely that the problem is in pycurl's C code, and that the error there simply went undetected before Python 2.3, appearing to work by luck. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-02 06:51 Message: Logged In: YES user_id=6656 Why do you think this is a bug in Python and not pycurl? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 From noreply at sourceforge.net Thu Oct 2 14:07:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 14:07:11 2003 Subject: [Python-bugs-list] [ python-Bugs-816476 ] Fatal Python error: GC object already tracked Message-ID: Bugs item #816476, was opened at 2003-10-02 10:42 Message generated for change (Comment added) made by thenninger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thorsten Henninger (thenninger) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python error: GC object already tracked Initial Comment: Fatal Python error: GC object already tracked OS: Windows 2000 Server (Service Pack 4) Python: 2.3.1 (#47) pycurl: 7.10.6 I got this Fatal Error while fetching Webpages with pycurl. I do not have any other addiotional information. This error is reproducible and did not occur with Python2.2. Please contact me, if you need further information ---------------------------------------------------------------------- >Comment By: Thorsten Henninger (thenninger) Date: 2003-10-02 18:07 Message: Logged In: YES user_id=878819 thank you, that makes sense! i will notice pycurl and have a look in th pycurl source! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-02 16:25 Message: Logged In: YES user_id=31435 You should report this to the pycurl project. The specific error message you report is new in Python 2.3, doing a check for errnoneous usage of the Python C API. That check didn't exist in Python 2.2. While it's possible there's a previously unreported error in Python 2.3 here, it's much more likely that the problem is in pycurl's C code, and that the error there simply went undetected before Python 2.3, appearing to work by luck. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-02 10:51 Message: Logged In: YES user_id=6656 Why do you think this is a bug in Python and not pycurl? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 From noreply at sourceforge.net Thu Oct 2 14:07:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 14:07:40 2003 Subject: [Python-bugs-list] [ python-Bugs-816344 ] Missing import in email example Message-ID: Bugs item #816344, was opened at 2003-10-02 01:05 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816344&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tony Meyer (anadelonbrin) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Missing import in email example Initial Comment: The "email-dir.py" example in the email module documentation is missing an import. The MIMEBase is used (when a generic file is found), but MIMEBase is not imported. Putting "from email.MIMEBase import MIMEBase" with the other imports fixes this. This is Python 2.3.1, and also the cvs that anon sf thinks is current. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816344&group_id=5470 From noreply at sourceforge.net Thu Oct 2 14:11:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 14:11:36 2003 Subject: [Python-bugs-list] [ python-Bugs-811070 ] Py2.2.3: Problem with Expat/XML/Zope on MacOSX 10.2.8 Message-ID: Bugs item #811070, was opened at 2003-09-23 06:00 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811070&group_id=5470 Category: XML Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Jung (ajung) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Py2.2.3: Problem with Expat/XML/Zope on MacOSX 10.2.8 Initial Comment: Trying to run Python 2.2.3 under MacOSX with Zope fails: Python has been built against the latest Expat Sources (1.96.6) Traceback (most recent call last): File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/Zope/Startup/run.py", line 14, in ? run() File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/Zope/Startup/run.py", line 8, in run opts.realize() File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/zdaemon/zdoptions.py", line 257, in realize self.load_schema() File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/zdaemon/zdoptions.py", line 298, in load_schema self.schema = ZConfig.loadSchema(self.schemafile) File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/ZConfig/loader.py", line 36, in loadSchema return SchemaLoader().loadURL(url) File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/ZConfig/loader.py", line 70, in loadURL return self.loadResource(r) File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/ZConfig/loader.py", line 134, in loadResource self.registry, self) File "/Users/ajung/sandboxes/plone1.1/Zope/lib/python/ZConfig/schema.py", line 42, in parseResource xml.sax.parse(resource.file, parser) File "/opt/python-2.2.3/lib/python2.2/site-packages/_xmlplus/sax/__init__.py", line 31, in parse parser.parse(filename_or_stream) File "/opt/python-2.2.3/lib/python2.2/site-packages/_xmlplus/sax/expatreader.py", line 106, in parse self.reset() File "/opt/python-2.2.3/lib/python2.2/site-packages/_xmlplus/sax/expatreader.py", line 261, in reset self._parser = expat.ParserCreate(intern = self._interning) TypeError: 'intern' is an invalid keyword argument for this function ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811070&group_id=5470 From noreply at sourceforge.net Thu Oct 2 14:13:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 14:13:43 2003 Subject: [Python-bugs-list] [ python-Bugs-816725 ] mark deprecated modules in indexes Message-ID: Bugs item #816725, was opened at 2003-10-02 14: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=816725&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: mark deprecated modules in indexes Initial Comment: J. David Ibanez (jdavid at itaapy.com) suggested via email: It would be nice if the "Global Module Index" showed the deprecated modules clearly separated from the non deprecated modules. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816725&group_id=5470 From noreply at sourceforge.net Thu Oct 2 16:12:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 16:12:56 2003 Subject: [Python-bugs-list] [ python-Bugs-812804 ] 2.3.1 re_test causes sigsegv Message-ID: Bugs item #812804, was opened at 2003-09-25 18:43 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812804&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin L?thi (tnoo) Assigned to: Fredrik Lundh (effbot) Summary: 2.3.1 re_test causes sigsegv Initial Comment: I compiled Python 2.3.1 on a SuSE Linux 8.1 system Python 2.3.1 (#1, Sep 25 2003, 14:13:07) [GCC 3.3 20030226 (prerelease) (SuSE Linux)] on linux2 running the test, I get sigsev python test/test_re.py test_anyall (__main__.ReTests) ... ok test_basic_re_sub (__main__.ReTests) ... ok test_bigcharset (__main__.ReTests) ... ok test_bug_113254 (__main__.ReTests) ... ok test_bug_114660 (__main__.ReTests) ... ok test_bug_117612 (__main__.ReTests) ... ok Segmentation fault Thanks Martin ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-02 15:12 Message: Logged In: YES user_id=139865 Cannot reproduce with Python 2.3.2rc1, Red Hat 7.3, GCC 3.3.1, and glibc-2.2.5-43. Note that reporter is using a prerelease of GCC 3.3; the proper release is 20030514. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-26 12:32 Message: Logged In: YES user_id=29957 Hm. What version of libc is that system running? I've not got a gcc 3.3 anywhere handy - could you try rebuilding the _sre.c file without optimisation? touch Modules/_sre.c make OPT="-g" should do it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812804&group_id=5470 From noreply at sourceforge.net Thu Oct 2 16:51:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 16:51:56 2003 Subject: [Python-bugs-list] [ python-Bugs-811028 ] configure: curses busted on Freebsd/Mac OSX Message-ID: Bugs item #811028, was opened at 2003-09-23 09:50 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard Jones (richard) Assigned to: Nobody/Anonymous (nobody) Summary: configure: curses busted on Freebsd/Mac OSX Initial Comment: Anthony said to log this: checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug- autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## I'll attach the text of the report and the configure output too since I'm pretty sure the above won't be ligible once sf's tracker's finished with it. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-10-02 22:48 Message: Logged In: YES user_id=45365 On Jaguar _XOPEN_SOURCE_EXTENDED is only used in curses.h and ncurses.h, and one other place defines it (httpd/ap_config.h). The other good news is that on Panther the problem doesn't exist. ---------------------------------------------------------------------- Comment By: Benno Rice (benno) Date: 2003-10-01 18:59 Message: Logged In: YES user_id=9925 There is a bug in FreeBSD's ncurses.h where it checks to see if a macro called __wchar_t is defined before attempting to typedef it's own wchar_t. This causes problems because __wchar_t (and wchar_t) exist, but __wchar_t is a typedef not a macro. This is solved by removing _XOPEN_SOURCE_EXTENDED which is what triggers this check. Removing _XOPEN_SOURCE_EXTENDED should have no other implications on FreeBSD. There is a patch that disables _XOPEN_SOURCE_EXTENDED for FreeBSD at http://jeamland.net/~benno/configure.in.diff ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 18:42 Message: Logged In: YES user_id=29957 Ok. Ripping out the line AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, Define to activate Unix95-and-earlier features) from configure.in fixes the problem on FreeBSD. The only occurance of _XOPEN_SOURCE_EXTENDED in FreeBSD's headers is ncurses.h. FreeBSD will hopefully fix the bug in their headers to remove the problem in a future version of the code. Jack or Richard, can you see if _XOPEN_SOURCE_EXTENDED is used anywhere else on Mac OS X? If not, we could put a workaround in for Mac OS X and FreeBSD to not define the header. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 18:28 Message: Logged In: YES user_id=29957 Benno tells me that there's a patch for configure available at http://jeamland.net/~benno/configure.in.diff It'll fix FreeBSD, but not Mac OS X. Argh. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-10-01 17:04 Message: Logged In: YES user_id=45365 I've also seen this. I don't have the time to dive into this, but I think it has to do with gcc 3.3. I had just upgraded to gcc 3.3 from 3.1, and before the upgrade I never saw the problem. Is everyone who sees the problem using gcc 3.3, by any chance? If so then it's probably an incompatibility between curses.h and that compiler. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 10:52 Message: Logged In: YES user_id=29957 Unless a FreeBSD or Mac OS X expert can step forward in the next day and suggest a fix, this isn't going to be fixed for 2.3.2(final). I can't spend any more time on it. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-10-01 01:29 Message: Logged In: YES user_id=6405 The diagnosis on OS X is similar, and the trigger for defining wchar_t in stdlib.h is the absence of _ANSI_SOURCE. Making it not define _XOPEN_SOURCE_EXTENDED also fixes the compile as per your FreeBSD fix. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-30 16:24 Message: Logged In: YES user_id=29957 Looking into it a bit on FreeBSD: /usr/include/ncurses.h:236: conflicting types for `wchar_t' /usr/include/stdlib.h:58: previous declaration of `wchar_t' and poking around a bit I find that stdlib.h defines wchar_t as an 'int', while ncurses.h defines it as 'unsigned long'. This is on FreeBSD 4.8. Extracting the failing configure code and making it not define _XOPEN_EXTENDED_SOURCE makes the test succeed, but I have no idea if this is an appropriate fix. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-27 10:36 Message: Logged In: YES user_id=6405 (I didn't mention it in the report, only to Anthony : this is on OSX) The patch doesn't alter the configure behaviour. I can't remember how to run the curses test - "make test" skips it (the curses module is built though). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-27 09:53 Message: Logged In: YES user_id=21627 Can you try the patch in python.org/sf/806800 ? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-23 10:28 Message: Logged In: YES user_id=6405 "make test" also reports: test_curses test test_curses crashed -- _curses.error: curs_set() returned ERR ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-23 10:14 Message: Logged In: YES user_id=29957 creosote (which is a freebsd machine) also sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 From noreply at sourceforge.net Thu Oct 2 17:00:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 17:00:23 2003 Subject: [Python-bugs-list] [ python-Bugs-816810 ] webbrowser.open hangs under certain conditions Message-ID: Bugs item #816810, was opened at 2003-10-02 23: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=816810&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Nobody/Anonymous (nobody) Summary: webbrowser.open hangs under certain conditions Initial Comment: On Unix, if you have galeon installed and no BROWSER environment variable, webbrowser.open('http://...') will hang if there is no galeon running at the time of the call. The problem is, webbrowser.open calls "galeon ". If a galeon instance is running, the new invocation will signal the old about the URL and then exit. If there is no galeon instance running, the new instance will do the job itself and not exit, so the call to webbrowser.open() will hang until you exit galeon. Skip had this to say: In the meantime, it looks like if you modify the definition of cmd in Galeon._remote to cmd = "%s %s %s & >/dev/null 2>&1" % (self.name, raise_opt, action) that webbrowser.open() should return for you. I'm not sure the '&' is sufficient though. You may lose the Galeon instance if you then exit from the Python interpreter. In general, the code in webbrowser._remote() looks a bit hackish. I'm not sure I like this: rc = os.system(cmd) if rc: import time os.system("%s >/dev/null 2>&1 &" % self.name) time.sleep(PROCESS_CREATION_DELAY) rc = os.system(cmd) Oh well, it's what we're stuck with... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816810&group_id=5470 From noreply at sourceforge.net Thu Oct 2 18:26:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 18:26:12 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 12:31 Message generated for change (Comment added) made by eurosys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Nobody/Anonymous (nobody) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Roger Erens (eurosys) Date: 2003-10-03 00:25 Message: Logged In: YES user_id=878033 I uploaded both the config.log and the pyconfig.h for 2.2.3. I'm curious what you think of it. The system is quite old, indeed (but we have even older among our customer base, as they are not very much inclined to investing in hardware!). It is much used, though. Regards, Roger ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 18:19 Message: Logged In: YES user_id=6656 Can you attach the config.log for 2.2.3? I'm now a little curious as to how dynamic linking ever worked on this system (which is fairly old, right?) ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-01 17:45 Message: Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 17:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Thu Oct 2 22:45:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 22:45:16 2003 Subject: [Python-bugs-list] [ python-Bugs-812202 ] randint is always even Message-ID: Bugs item #812202, was opened at 2003-09-24 23:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald L. Rivest (ronrivest) Assigned to: Raymond Hettinger (rhettinger) Summary: randint is always even Initial Comment: The result of random.randint(2**64,2**65-1) is always even! (I was trying to find some large prime numbers, and was puzzled by the fact that none were turning up. Finally, I discovered that randint wasn't really returning "random" integers as desired, but only even ones.) I'm not sure what the cause of the problem is, but randint should work properly, even when the given endpoints are large... Thanks... Ron Rivest ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-02 21:45 Message: Logged In: YES user_id=80475 Here is a patch for Py2.4 that: * implements getrandbits(k) in C * modifies randrange() to use getrandbits() when available * modified randrange() to warn for large ranges whenever getrandbits() is not available * creates a BaseRandom class for generator subclassing A separate patch for Py2.3.3 will be loaded that extends randrange() for only the MersenneTwister and makes no API changes or assumptions about other generators. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-28 02:42 Message: Logged In: YES user_id=80475 A cleaner, faster patch is attached along with tests. Before it goes in, the second assert can be commented out. Unless Tim comes-up with a better idea about obtaining the information content of a call to random(), I think the 53-bit assumption is fine (a bar for core generators to live up to). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-26 23:40 Message: Logged In: YES user_id=80475 Attached is a first draft of a patch. It works but I don't like the globals for 53 bits per random float because the WichmannHill generator supplies fewer bits than that. I don't see a general way to find out how many bits per random call are offered by an underlying generator. A more conservative, but slower approach is to assume on 32 bits and, if there are more, just throw them away. Ideas are welcome. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-25 19:07 Message: Logged In: YES user_id=31435 Ya, something like that indeed. You might enjoy writing the core in C . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-25 12:10 Message: Logged In: YES user_id=80475 If the range is too large, instead of raising an exception, how about calling a _randbigint routine that builds up the random selection using repeated calls to the underlying generator. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-25 10:23 Message: Logged In: YES user_id=31435 No disagreement here. I'd rather fix the code than the docs, and a fix can take two forms: raise an exception if the full range of ints can't be delivered, or deliver the full range of ints. If anyone wants to take this on, I think the latter ("do a right thing") may be much more practical than it used to be, given the new-in-2.3 Twister impelementation -- we can generate long pseudo-random bitstrings quickly now (at least at the C level), but couldn't before 2.3. ---------------------------------------------------------------------- Comment By: Ronald L. Rivest (ronrivest) Date: 2003-09-25 09:56 Message: Logged In: YES user_id=863876 If the code is not going to be fixed, then the documentation should be updated. I am well aware of other approaches to generating large random numbers, but was misled by the documentation Python provides. The documentation should make it clear when the code violates its "contract" (i.e. doesn't generate all integers in the range). I prefer the code being fixed best, but also feel that the code should raise an exception if it can't honor the contract implied in its documentation. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-25 00:16 Message: Logged In: YES user_id=31435 The cause is that randint takes a pseudo-random float (C double in [0, 1),), multiplies it by (hi-lo+1), then truncates and adds that to lo. Since a double on your box almost certainly has only 53 bits of precision, and your multiplier effectively moves the radix point 64 bits "to the right", I expect the last 11 bits you see will always be 0. Under Python 2.3, which uses the Mersenne Twister to generate random doubles, this does appear to be the case: >>> from random import randint >>> def f(): ... return randint(2**64, 2**65-1) ... >>> hex(f()) '0x11EDD95B72CEF4000L' >>> hex(f()) '0x1DD69BF4B39C65000L' >>> hex(f()) '0x13328DC9C1C733800L' >>> hex(f()) '0x1E65B47170C057800L' >>> Under earlier versions of Python, it may be even worse than that. It takes a fundamentally different kind of algorithm to generate arbitrarily long random ints. Here's a link to one such for Python: http://www.faqts.com/knowledge_base/view.phtml/aid/4406 I doubt the implementation of randint() will change, since most people want fast-as-possible generation of mountains of small integers, and there's a tradeoff between catering to that and catering to extreme inputs. The randint docs should change, though (I think randint() used to raise an exception when fed arguments as large as the ones you're using; I suspect, but don't know, that we lost the helpful exception as an unintended consequence of the long-term effort to eradicate the user-visible distinction between Python ints (machine C longs) and Python longs (unbounded integers)). BTW, given what you're doing, you may want to install one of the Python wrappers for GNU GMP. Python's unbounded-int arithmetic implementation is extremely portable and reliable, but buys those in part by not caring much about speed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470 From noreply at sourceforge.net Thu Oct 2 23:09:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 2 23:09:35 2003 Subject: [Python-bugs-list] [ python-Bugs-816929 ] term.h present but cannot be compiled Message-ID: Bugs item #816929, was opened at 2003-10-03 15: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=816929&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nicholas Hawthorn (nhawthorn) Assigned to: Nobody/Anonymous (nobody) Summary: term.h present but cannot be compiled Initial Comment: This report relates to building Python 2.3.1 on Irix 6.5. Here is stderr output from: configure --with-cxx=CC configure: WARNING: term.h: present but cannot be compiled configure: WARNING: term.h: check for missing prerequisite headers? configure: WARNING: term.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## I did submit a bug report -- they said the issue is known. "make" after this gave the following error, among others:- cc-1059 cc: ERROR File = /xlv4/med_psyc/nhn/py231/Python-2.3.1/Modules/termios.c , Line = 633 A function call is not allowed in a constant expression. {"CWERASE", CWERASE}, By experiment on a very short C program, term.h needs curses.h to be included before it, and will not compile correctly otherwise. This would give a number of errors. Thanks and best wishes! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816929&group_id=5470 From noreply at sourceforge.net Fri Oct 3 00:09:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 00:09:14 2003 Subject: [Python-bugs-list] [ python-Bugs-816946 ] Float Multiplication Message-ID: Bugs item #816946, was opened at 2003-10-02 22: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=816946&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Victor Demaria (vktor) Assigned to: Fredrik Lundh (effbot) Summary: Float Multiplication Initial Comment: Why (1.16 * 100) is not the same than (1.16 * 10 * 10)? I tried 1.16*100. also and it is = 115.99999999; but if I do 1.16*10*10 I get 116. Thanks.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816946&group_id=5470 From noreply at sourceforge.net Fri Oct 3 03:48:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 03:48:53 2003 Subject: [Python-bugs-list] [ python-Bugs-816946 ] Float Multiplication Message-ID: Bugs item #816946, was opened at 2003-10-03 06:09 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816946&group_id=5470 >Category: Documentation Group: Python 2.3 >Status: Deleted >Resolution: Invalid Priority: 5 Submitted By: Victor Demaria (vktor) Assigned to: Fredrik Lundh (effbot) Summary: Float Multiplication Initial Comment: Why (1.16 * 100) is not the same than (1.16 * 10 * 10)? I tried 1.16*100. also and it is = 115.99999999; but if I do 1.16*10*10 I get 116. Thanks.... ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2003-10-03 09:48 Message: Logged In: YES user_id=38376 The answer to your question can be found in the Python tutorial, and has nothing to do with regular expressions: http://www.python.org/doc/tut/node14.html Please don't use the bug tracker to ask for help in the future; I suggest asking on comp.lang.python (for other help forums, see www.python.org). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816946&group_id=5470 From noreply at sourceforge.net Fri Oct 3 07:10:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 07:10:40 2003 Subject: [Python-bugs-list] [ python-Bugs-474836 ] Tix not included in windows distribution Message-ID: Bugs item #474836, was opened at 2001-10-25 11:22 Message generated for change (Comment added) made by digulla You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Tim Peters (tim_one) Summary: Tix not included in windows distribution Initial Comment: Although there is a Tix.py available, there is no Tix support in the precomiled Python-distribution for windows. So import Tix works fine, but root = Tix.Tk() results in TclError: package not found. It is possible to circumvent this problem by installing a regular Tcl/Tk distribution (e.g. in c:\programme\tcl) and installing Tix in the regular Tcl-path (i.e. tcl\lib). Mathias ---------------------------------------------------------------------- Comment By: Aaron Optimizer Digulla (digulla) Date: 2003-10-03 11:10 Message: Logged In: YES user_id=606 loewis, when will your package show up in the official Python distribution? It's still not there in 2.3.2 :-( ---------------------------------------------------------------------- Comment By: Aaron Optimizer Digulla (digulla) Date: 2003-07-28 13:22 Message: Logged In: YES user_id=606 The Tix8184.dll is still missing in Python 2.3c2. The included Tix8183.dll (which is in the directory tcl\tix8.1\ along with a couple of other dlls -> can't be found by Python) is linked against Tcl/Tk 8.3. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-15 12:40 Message: Logged In: YES user_id=21627 I found that the instructions need slight modification: In step 2, use tk...\mkd.bat for mkdir. Apart from that, these instructions work fine for me, now. I have made a binary release of tix8.1 for Python 2.3 at http://www.dcl.hpi.uni-potsdam.de/home/loewis/tix8.1.zip The tix8184.dll goes to DLLs, the tix8.1 subdirectory goes to tcl. It differs from the standard tix8.1 subdirectory only in fixing the path to the DLLs directory. To test whether this works, execute Demo/tix/tixwidgets.py. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-04-26 10:22 Message: Logged In: YES user_id=21627 I still think Python should include Tix. Here are some instructions on how to make Tix 8.1.4 work: 1. Unpack as a sibling of tcl8.4.1 and tk8.4.1 2. Edit win\common.mk, to set the following variables TCL_VER=8.4 INSTALLDIR= MKDIR=mkdir 3. Edit win\makefile.vc, to set the following variables TOOLS32= TOOLS32_rc= 4. Edit win\tk\pkgindex.tcl, to replace lappend dirs ../../Dlls with lappend dirs [file join [file dirname [info nameofexe]] Dlls] 5. nmake -f makefile.vc 6. nmake -f makefile.vc install 7. Copy INSTALLDIR\bin\tix8184.dll to \DLLs 8. Optionally copy tix8184.lib somewhere 9. copy INSTALLDIR\lib\tix8.1 into \tcl With these instructions, invoking t.tk.eval("package require Tix") succeeds. For some reason, Tix won't still find any of the commands; I'll investigate this later. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 09:14 Message: Logged In: YES user_id=33229 My you're courageous - going with a version of Tcl that doesn't even pass its own tests :-) Been there, seen it, done it .... 8.1.4 will be out this week, which compiles with 8.4 but I don't expect it to "support" 8.4 for a while yet (they added more problems in 8.4.1). 8.3.5 is definitely "supported". Check back with me before 2.3 goes into beta and I'll do another minor release if necessary. Maybe Tk will test clean then. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-20 01:36 Message: Logged In: YES user_id=31435 Parents shouldn't disagree in front of their children . Not all the Tcl or Tk tests (their tests, not ours) passed when I built 8.4.1, but I couldn't (and can't) make time to dig into that, and all the Python stuff I tried worked fine. So I don't fear 8.4, and am inclined to accept Martin's assurance that 8.4 is best for Python. We intend to put out the first 2.3 Python alpha by the end of the year, and my bet is it won't be a minute before that. If Tix 8.1.4 is at RC3 now, I'd *guess* you'll have a final release out well before then. Yes? No? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-19 22:12 Message: Logged In: YES user_id=21627 I think the recommendation cannot apply to Python; I'm very much in favour of releasing Python 2.3 with Tk 8.4.x. So the question then is whether Python 2.3 should include Tix 8.1.4 or no Tix at all, and at what time Tix 8.1.4 can be expected. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 19:10 Message: Logged In: YES user_id=33229 Look on http://tix.sourceforge.net/download.shtml for Tix 8.1.4 RC3. It works with Tk 8.4.1 and passes the test suite, but there are still issues with Tk 8.4 and it has not been widely tested with yet with 8.4.1, so we still recommend 8.3.5. (Tcl major releases often aren't stable until patch .3 or so.) If you have any problems let me know directly by email and I'll try and help. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-18 16:35 Message: Logged In: YES user_id=31435 Does Tix 8.1.3 play with Tcl/Tk 8.4.1? The 2.3. Windows distro is set up to include the latter now. The win\common.mak file from Tix 8.1.3 doesn't have a section for Tcl/Tk 8.4, though. There appear to be several reasons Tix won't compile on my box anyway without fiddling the Tix makefiles (e.g., my VC doesn't live in \DevStudio), so before spending more time on that I'd like to know whether it's doomed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 14:52 Message: Logged In: YES user_id=6380 I support this. Tim, I know you're not a big Tk user (to say the least). I'll offer to help in person. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 07:30 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 05:34 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-23 03:34 Message: Logged In: YES user_id=6380 Yes, for 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-10 01:48 Message: Logged In: YES user_id=31435 Guido, do you want me to spend time on this? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2002-03-07 13:38 Message: Logged In: YES user_id=361926 Thanks. Mathias ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-25 12:57 Message: Logged In: YES user_id=21627 The zip file is slightly too large for SF, so it is now at http://www.informatik.hu- berlin.de/~loewis/python/tix813win.zip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-25 12:56 Message: Logged In: YES user_id=21627 Building Tix from sources is non-trivial, and I could not find any recent Windows binary distribution (based on Tix 8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, as a drop-in into the Python binary distribution. Compared to the original distribution, only tix8.1 \pkgIndex.tcl required tweaking, to tell it that tix8183.dll can be found in the DLLs subdirectory. Also, unless TIX_LIBRARY is set, the Tix tcl files *must* live in tcl\tix8.1, since tix8183.dll will look in TCL_LIBRARY\..\tix (among other locations). If a major Tcl release happens before Python 2.3 is released (and it is then still desirable to distribute Python with Tix), these binaries need to be regenerated. Would these instructions (unpack zip file into distribution tree) be precise enough to allow incorporation into the windows installer? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2001-10-29 11:53 Message: Logged In: YES user_id=361926 As mentioned in the mail above (by me, Mathias), Tix is a package belonging to Tcl/Tk (to be found on sourceforge: tix.sourceforge.net, or via the Python home page - tkinter link). Everything needed can be found there, just read about it (and dont forget about the winking, eyes might be getting dry) Mathias ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-25 18:26 Message: Logged In: YES user_id=31435 I don't know anything about Tix, so if somebody wants this in the Windows installer, they're going to have to explain exactly (by which I mean exactly <0.5 wink>) what's needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 From noreply at sourceforge.net Fri Oct 3 07:17:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 07:17:57 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 11:31 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Nobody/Anonymous (nobody) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-03 12:17 Message: Logged In: YES user_id=6656 Curioser and curioser. The difference seems to be that configure for 2.2.3 passes "-belf" to cc when checking for dlopen but configure for 2.3 doesn't. I actually have an idea how this happens: in 2.3, the CFLAGS variable was split up into BASECFLAGS and OPT. We know we need -belf on SCO, so we stuff that into BASECFLAGS. However, this *doesn't* make the rest of the configure tests use -belf -- result breakage. (Martin, are you reading this? Does this sound reasonable?) Roger, can you try the attached patch? It's a bit of a hack... ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-02 23:25 Message: Logged In: YES user_id=878033 I uploaded both the config.log and the pyconfig.h for 2.2.3. I'm curious what you think of it. The system is quite old, indeed (but we have even older among our customer base, as they are not very much inclined to investing in hardware!). It is much used, though. Regards, Roger ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 17:19 Message: Logged In: YES user_id=6656 Can you attach the config.log for 2.2.3? I'm now a little curious as to how dynamic linking ever worked on this system (which is fairly old, right?) ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-01 16:45 Message: Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 16:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 15:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Fri Oct 3 08:37:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 08:37:48 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 12:31 Message generated for change (Comment added) made by eurosys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Nobody/Anonymous (nobody) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Roger Erens (eurosys) Date: 2003-10-03 14:37 Message: Logged In: YES user_id=878033 Hi Michael, nice hack for a first time: no warnings this time, as you can see in the attached make.out. Thanks a lot! Only a few compiler errors remain, but I cannot be bothered with them right now. So just FYI (after running make; make clean): >make > make.out "Objects/stringobject.c", line 1765: warning: statement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/getaddrinfo.c", line 556: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/getnameinfo.c", line 184: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2374: error: undefi ned symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2972: error: undefi ned symbol: AF_INET6 "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: undefi ned symbol: INET_ADDRSTRLEN "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: integr al constant expression expected "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3055: warning: stat ement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1553: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1554: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1964: warning: ass ignment type mismatch ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 13:17 Message: Logged In: YES user_id=6656 Curioser and curioser. The difference seems to be that configure for 2.2.3 passes "-belf" to cc when checking for dlopen but configure for 2.3 doesn't. I actually have an idea how this happens: in 2.3, the CFLAGS variable was split up into BASECFLAGS and OPT. We know we need -belf on SCO, so we stuff that into BASECFLAGS. However, this *doesn't* make the rest of the configure tests use -belf -- result breakage. (Martin, are you reading this? Does this sound reasonable?) Roger, can you try the attached patch? It's a bit of a hack... ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-03 00:25 Message: Logged In: YES user_id=878033 I uploaded both the config.log and the pyconfig.h for 2.2.3. I'm curious what you think of it. The system is quite old, indeed (but we have even older among our customer base, as they are not very much inclined to investing in hardware!). It is much used, though. Regards, Roger ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 18:19 Message: Logged In: YES user_id=6656 Can you attach the config.log for 2.2.3? I'm now a little curious as to how dynamic linking ever worked on this system (which is fairly old, right?) ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-01 17:45 Message: Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 17:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Fri Oct 3 08:49:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 08:49:19 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 11:31 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) >Assigned to: Martin v. L?wis (loewis) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-03 13:49 Message: Logged In: YES user_id=6656 Glad to have my suspicions confirmed! The reason my patch was a hack is that it patches up SCO ok, but this is at least potentially a problem on other platforms. Given the lack of similar bug reports, though, perhaps it isn't. The remaining warnings look like different issues; should they become bothering I recommend opening new reports. Assigning to Martin, 'cause I'd like him to read my comment of 2003-10-03 12:17 before I check anything in (we missed 2.3.2, and I don't think 2.3.3 will be for a while). ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-03 13:37 Message: Logged In: YES user_id=878033 Hi Michael, nice hack for a first time: no warnings this time, as you can see in the attached make.out. Thanks a lot! Only a few compiler errors remain, but I cannot be bothered with them right now. So just FYI (after running make; make clean): >make > make.out "Objects/stringobject.c", line 1765: warning: statement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/getaddrinfo.c", line 556: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/getnameinfo.c", line 184: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2374: error: undefi ned symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2972: error: undefi ned symbol: AF_INET6 "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: undefi ned symbol: INET_ADDRSTRLEN "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: integr al constant expression expected "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3055: warning: stat ement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1553: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1554: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1964: warning: ass ignment type mismatch ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 12:17 Message: Logged In: YES user_id=6656 Curioser and curioser. The difference seems to be that configure for 2.2.3 passes "-belf" to cc when checking for dlopen but configure for 2.3 doesn't. I actually have an idea how this happens: in 2.3, the CFLAGS variable was split up into BASECFLAGS and OPT. We know we need -belf on SCO, so we stuff that into BASECFLAGS. However, this *doesn't* make the rest of the configure tests use -belf -- result breakage. (Martin, are you reading this? Does this sound reasonable?) Roger, can you try the attached patch? It's a bit of a hack... ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-02 23:25 Message: Logged In: YES user_id=878033 I uploaded both the config.log and the pyconfig.h for 2.2.3. I'm curious what you think of it. The system is quite old, indeed (but we have even older among our customer base, as they are not very much inclined to investing in hardware!). It is much used, though. Regards, Roger ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 17:19 Message: Logged In: YES user_id=6656 Can you attach the config.log for 2.2.3? I'm now a little curious as to how dynamic linking ever worked on this system (which is fairly old, right?) ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-01 16:45 Message: Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 16:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 15:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Fri Oct 3 09:13:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 09:13:55 2003 Subject: [Python-bugs-list] [ python-Bugs-474836 ] Tix not included in windows distribution Message-ID: Bugs item #474836, was opened at 2001-10-25 07: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=474836&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Nobody/Anonymous (nobody) Summary: Tix not included in windows distribution Initial Comment: Although there is a Tix.py available, there is no Tix support in the precomiled Python-distribution for windows. So import Tix works fine, but root = Tix.Tk() results in TclError: package not found. It is possible to circumvent this problem by installing a regular Tcl/Tk distribution (e.g. in c:\programme\tcl) and installing Tix in the regular Tcl-path (i.e. tcl\lib). Mathias ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-03 09:13 Message: Logged In: YES user_id=31435 Unassigned (doesn't look like I'll ever get time for this). ---------------------------------------------------------------------- Comment By: Aaron Optimizer Digulla (digulla) Date: 2003-10-03 07:10 Message: Logged In: YES user_id=606 loewis, when will your package show up in the official Python distribution? It's still not there in 2.3.2 :-( ---------------------------------------------------------------------- Comment By: Aaron Optimizer Digulla (digulla) Date: 2003-07-28 09:22 Message: Logged In: YES user_id=606 The Tix8184.dll is still missing in Python 2.3c2. The included Tix8183.dll (which is in the directory tcl\tix8.1\ along with a couple of other dlls -> can't be found by Python) is linked against Tcl/Tk 8.3. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-15 08:40 Message: Logged In: YES user_id=21627 I found that the instructions need slight modification: In step 2, use tk...\mkd.bat for mkdir. Apart from that, these instructions work fine for me, now. I have made a binary release of tix8.1 for Python 2.3 at http://www.dcl.hpi.uni-potsdam.de/home/loewis/tix8.1.zip The tix8184.dll goes to DLLs, the tix8.1 subdirectory goes to tcl. It differs from the standard tix8.1 subdirectory only in fixing the path to the DLLs directory. To test whether this works, execute Demo/tix/tixwidgets.py. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-04-26 06:22 Message: Logged In: YES user_id=21627 I still think Python should include Tix. Here are some instructions on how to make Tix 8.1.4 work: 1. Unpack as a sibling of tcl8.4.1 and tk8.4.1 2. Edit win\common.mk, to set the following variables TCL_VER=8.4 INSTALLDIR= MKDIR=mkdir 3. Edit win\makefile.vc, to set the following variables TOOLS32= TOOLS32_rc= 4. Edit win\tk\pkgindex.tcl, to replace lappend dirs ../../Dlls with lappend dirs [file join [file dirname [info nameofexe]] Dlls] 5. nmake -f makefile.vc 6. nmake -f makefile.vc install 7. Copy INSTALLDIR\bin\tix8184.dll to \DLLs 8. Optionally copy tix8184.lib somewhere 9. copy INSTALLDIR\lib\tix8.1 into \tcl With these instructions, invoking t.tk.eval("package require Tix") succeeds. For some reason, Tix won't still find any of the commands; I'll investigate this later. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 04:14 Message: Logged In: YES user_id=33229 My you're courageous - going with a version of Tcl that doesn't even pass its own tests :-) Been there, seen it, done it .... 8.1.4 will be out this week, which compiles with 8.4 but I don't expect it to "support" 8.4 for a while yet (they added more problems in 8.4.1). 8.3.5 is definitely "supported". Check back with me before 2.3 goes into beta and I'll do another minor release if necessary. Maybe Tk will test clean then. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-19 20:36 Message: Logged In: YES user_id=31435 Parents shouldn't disagree in front of their children . Not all the Tcl or Tk tests (their tests, not ours) passed when I built 8.4.1, but I couldn't (and can't) make time to dig into that, and all the Python stuff I tried worked fine. So I don't fear 8.4, and am inclined to accept Martin's assurance that 8.4 is best for Python. We intend to put out the first 2.3 Python alpha by the end of the year, and my bet is it won't be a minute before that. If Tix 8.1.4 is at RC3 now, I'd *guess* you'll have a final release out well before then. Yes? No? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-19 17:12 Message: Logged In: YES user_id=21627 I think the recommendation cannot apply to Python; I'm very much in favour of releasing Python 2.3 with Tk 8.4.x. So the question then is whether Python 2.3 should include Tix 8.1.4 or no Tix at all, and at what time Tix 8.1.4 can be expected. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 14:10 Message: Logged In: YES user_id=33229 Look on http://tix.sourceforge.net/download.shtml for Tix 8.1.4 RC3. It works with Tk 8.4.1 and passes the test suite, but there are still issues with Tk 8.4 and it has not been widely tested with yet with 8.4.1, so we still recommend 8.3.5. (Tcl major releases often aren't stable until patch .3 or so.) If you have any problems let me know directly by email and I'll try and help. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-18 11:35 Message: Logged In: YES user_id=31435 Does Tix 8.1.3 play with Tcl/Tk 8.4.1? The 2.3. Windows distro is set up to include the latter now. The win\common.mak file from Tix 8.1.3 doesn't have a section for Tcl/Tk 8.4, though. There appear to be several reasons Tix won't compile on my box anyway without fiddling the Tix makefiles (e.g., my VC doesn't live in \DevStudio), so before spending more time on that I'd like to know whether it's doomed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 09:52 Message: Logged In: YES user_id=6380 I support this. Tim, I know you're not a big Tk user (to say the least). I'll offer to help in person. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 02:30 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 00:34 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-22 22:34 Message: Logged In: YES user_id=6380 Yes, for 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-09 20:48 Message: Logged In: YES user_id=31435 Guido, do you want me to spend time on this? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2002-03-07 08:38 Message: Logged In: YES user_id=361926 Thanks. Mathias ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-25 07:57 Message: Logged In: YES user_id=21627 The zip file is slightly too large for SF, so it is now at http://www.informatik.hu- berlin.de/~loewis/python/tix813win.zip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-25 07:56 Message: Logged In: YES user_id=21627 Building Tix from sources is non-trivial, and I could not find any recent Windows binary distribution (based on Tix 8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, as a drop-in into the Python binary distribution. Compared to the original distribution, only tix8.1 \pkgIndex.tcl required tweaking, to tell it that tix8183.dll can be found in the DLLs subdirectory. Also, unless TIX_LIBRARY is set, the Tix tcl files *must* live in tcl\tix8.1, since tix8183.dll will look in TCL_LIBRARY\..\tix (among other locations). If a major Tcl release happens before Python 2.3 is released (and it is then still desirable to distribute Python with Tix), these binaries need to be regenerated. Would these instructions (unpack zip file into distribution tree) be precise enough to allow incorporation into the windows installer? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2001-10-29 06:53 Message: Logged In: YES user_id=361926 As mentioned in the mail above (by me, Mathias), Tix is a package belonging to Tcl/Tk (to be found on sourceforge: tix.sourceforge.net, or via the Python home page - tkinter link). Everything needed can be found there, just read about it (and dont forget about the winking, eyes might be getting dry) Mathias ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-25 14:26 Message: Logged In: YES user_id=31435 I don't know anything about Tix, so if somebody wants this in the Windows installer, they're going to have to explain exactly (by which I mean exactly <0.5 wink>) what's needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 From noreply at sourceforge.net Fri Oct 3 09:15:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 09:15:42 2003 Subject: [Python-bugs-list] [ python-Bugs-474836 ] Tix not included in windows distribution Message-ID: Bugs item #474836, was opened at 2001-10-25 13:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Thomas Heller (theller) Summary: Tix not included in windows distribution Initial Comment: Although there is a Tix.py available, there is no Tix support in the precomiled Python-distribution for windows. So import Tix works fine, but root = Tix.Tk() results in TclError: package not found. It is possible to circumvent this problem by installing a regular Tcl/Tk distribution (e.g. in c:\programme\tcl) and installing Tix in the regular Tcl-path (i.e. tcl\lib). Mathias ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:15 Message: Logged In: YES user_id=21627 Reassigning to Thomas, who is doing Windows releases these days. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-03 15:13 Message: Logged In: YES user_id=31435 Unassigned (doesn't look like I'll ever get time for this). ---------------------------------------------------------------------- Comment By: Aaron Optimizer Digulla (digulla) Date: 2003-10-03 13:10 Message: Logged In: YES user_id=606 loewis, when will your package show up in the official Python distribution? It's still not there in 2.3.2 :-( ---------------------------------------------------------------------- Comment By: Aaron Optimizer Digulla (digulla) Date: 2003-07-28 15:22 Message: Logged In: YES user_id=606 The Tix8184.dll is still missing in Python 2.3c2. The included Tix8183.dll (which is in the directory tcl\tix8.1\ along with a couple of other dlls -> can't be found by Python) is linked against Tcl/Tk 8.3. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-15 14:40 Message: Logged In: YES user_id=21627 I found that the instructions need slight modification: In step 2, use tk...\mkd.bat for mkdir. Apart from that, these instructions work fine for me, now. I have made a binary release of tix8.1 for Python 2.3 at http://www.dcl.hpi.uni-potsdam.de/home/loewis/tix8.1.zip The tix8184.dll goes to DLLs, the tix8.1 subdirectory goes to tcl. It differs from the standard tix8.1 subdirectory only in fixing the path to the DLLs directory. To test whether this works, execute Demo/tix/tixwidgets.py. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-04-26 12:22 Message: Logged In: YES user_id=21627 I still think Python should include Tix. Here are some instructions on how to make Tix 8.1.4 work: 1. Unpack as a sibling of tcl8.4.1 and tk8.4.1 2. Edit win\common.mk, to set the following variables TCL_VER=8.4 INSTALLDIR= MKDIR=mkdir 3. Edit win\makefile.vc, to set the following variables TOOLS32= TOOLS32_rc= 4. Edit win\tk\pkgindex.tcl, to replace lappend dirs ../../Dlls with lappend dirs [file join [file dirname [info nameofexe]] Dlls] 5. nmake -f makefile.vc 6. nmake -f makefile.vc install 7. Copy INSTALLDIR\bin\tix8184.dll to \DLLs 8. Optionally copy tix8184.lib somewhere 9. copy INSTALLDIR\lib\tix8.1 into \tcl With these instructions, invoking t.tk.eval("package require Tix") succeeds. For some reason, Tix won't still find any of the commands; I'll investigate this later. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-12-11 10:14 Message: Logged In: YES user_id=33229 My you're courageous - going with a version of Tcl that doesn't even pass its own tests :-) Been there, seen it, done it .... 8.1.4 will be out this week, which compiles with 8.4 but I don't expect it to "support" 8.4 for a while yet (they added more problems in 8.4.1). 8.3.5 is definitely "supported". Check back with me before 2.3 goes into beta and I'll do another minor release if necessary. Maybe Tk will test clean then. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-20 02:36 Message: Logged In: YES user_id=31435 Parents shouldn't disagree in front of their children . Not all the Tcl or Tk tests (their tests, not ours) passed when I built 8.4.1, but I couldn't (and can't) make time to dig into that, and all the Python stuff I tried worked fine. So I don't fear 8.4, and am inclined to accept Martin's assurance that 8.4 is best for Python. We intend to put out the first 2.3 Python alpha by the end of the year, and my bet is it won't be a minute before that. If Tix 8.1.4 is at RC3 now, I'd *guess* you'll have a final release out well before then. Yes? No? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-11-19 23:12 Message: Logged In: YES user_id=21627 I think the recommendation cannot apply to Python; I'm very much in favour of releasing Python 2.3 with Tk 8.4.x. So the question then is whether Python 2.3 should include Tix 8.1.4 or no Tix at all, and at what time Tix 8.1.4 can be expected. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-19 20:10 Message: Logged In: YES user_id=33229 Look on http://tix.sourceforge.net/download.shtml for Tix 8.1.4 RC3. It works with Tk 8.4.1 and passes the test suite, but there are still issues with Tk 8.4 and it has not been widely tested with yet with 8.4.1, so we still recommend 8.3.5. (Tcl major releases often aren't stable until patch .3 or so.) If you have any problems let me know directly by email and I'll try and help. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-18 17:35 Message: Logged In: YES user_id=31435 Does Tix 8.1.3 play with Tcl/Tk 8.4.1? The 2.3. Windows distro is set up to include the latter now. The win\common.mak file from Tix 8.1.3 doesn't have a section for Tcl/Tk 8.4, though. There appear to be several reasons Tix won't compile on my box anyway without fiddling the Tix makefiles (e.g., my VC doesn't live in \DevStudio), so before spending more time on that I'd like to know whether it's doomed. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 15:52 Message: Logged In: YES user_id=6380 I support this. Tim, I know you're not a big Tk user (to say the least). I'll offer to help in person. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 08:30 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 06:34 Message: Logged In: YES user_id=33229 I would really like to see Tix in 2.3 and will be glad to help. AFAIK there are no major issues with tix-8.1.3 and Python 2.x and it should be a simple drop in of a cannonically compiled Tix. If there are any issues that need dealing with at Tix's end, I'll be glad to put out a new minor release of Tix to address them. On Python's end I've suggested a fix for http://python.org/sf/564729 FYI, please also see my comments for bug 632323. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-03-23 04:34 Message: Logged In: YES user_id=6380 Yes, for 2.3. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-03-10 02:48 Message: Logged In: YES user_id=31435 Guido, do you want me to spend time on this? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2002-03-07 14:38 Message: Logged In: YES user_id=361926 Thanks. Mathias ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-25 13:57 Message: Logged In: YES user_id=21627 The zip file is slightly too large for SF, so it is now at http://www.informatik.hu- berlin.de/~loewis/python/tix813win.zip ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-02-25 13:56 Message: Logged In: YES user_id=21627 Building Tix from sources is non-trivial, and I could not find any recent Windows binary distribution (based on Tix 8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, as a drop-in into the Python binary distribution. Compared to the original distribution, only tix8.1 \pkgIndex.tcl required tweaking, to tell it that tix8183.dll can be found in the DLLs subdirectory. Also, unless TIX_LIBRARY is set, the Tix tcl files *must* live in tcl\tix8.1, since tix8183.dll will look in TCL_LIBRARY\..\tix (among other locations). If a major Tcl release happens before Python 2.3 is released (and it is then still desirable to distribute Python with Tix), these binaries need to be regenerated. Would these instructions (unpack zip file into distribution tree) be precise enough to allow incorporation into the windows installer? ---------------------------------------------------------------------- Comment By: Mathias Palm (monos) Date: 2001-10-29 12:53 Message: Logged In: YES user_id=361926 As mentioned in the mail above (by me, Mathias), Tix is a package belonging to Tcl/Tk (to be found on sourceforge: tix.sourceforge.net, or via the Python home page - tkinter link). Everything needed can be found there, just read about it (and dont forget about the winking, eyes might be getting dry) Mathias ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-10-25 20:26 Message: Logged In: YES user_id=31435 I don't know anything about Tix, so if somebody wants this in the Windows installer, they're going to have to explain exactly (by which I mean exactly <0.5 wink>) what's needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470 From noreply at sourceforge.net Fri Oct 3 09:26:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 09:26:46 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 12:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Martin v. L?wis (loewis) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:26 Message: Logged In: YES user_id=21627 I agree it is a hack. Without testing anything right know, I think all configure tests should run with BASECFLAGS. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 14:49 Message: Logged In: YES user_id=6656 Glad to have my suspicions confirmed! The reason my patch was a hack is that it patches up SCO ok, but this is at least potentially a problem on other platforms. Given the lack of similar bug reports, though, perhaps it isn't. The remaining warnings look like different issues; should they become bothering I recommend opening new reports. Assigning to Martin, 'cause I'd like him to read my comment of 2003-10-03 12:17 before I check anything in (we missed 2.3.2, and I don't think 2.3.3 will be for a while). ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-03 14:37 Message: Logged In: YES user_id=878033 Hi Michael, nice hack for a first time: no warnings this time, as you can see in the attached make.out. Thanks a lot! Only a few compiler errors remain, but I cannot be bothered with them right now. So just FYI (after running make; make clean): >make > make.out "Objects/stringobject.c", line 1765: warning: statement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/getaddrinfo.c", line 556: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/getnameinfo.c", line 184: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2374: error: undefi ned symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2972: error: undefi ned symbol: AF_INET6 "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: undefi ned symbol: INET_ADDRSTRLEN "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: integr al constant expression expected "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3055: warning: stat ement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1553: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1554: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1964: warning: ass ignment type mismatch ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 13:17 Message: Logged In: YES user_id=6656 Curioser and curioser. The difference seems to be that configure for 2.2.3 passes "-belf" to cc when checking for dlopen but configure for 2.3 doesn't. I actually have an idea how this happens: in 2.3, the CFLAGS variable was split up into BASECFLAGS and OPT. We know we need -belf on SCO, so we stuff that into BASECFLAGS. However, this *doesn't* make the rest of the configure tests use -belf -- result breakage. (Martin, are you reading this? Does this sound reasonable?) Roger, can you try the attached patch? It's a bit of a hack... ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-03 00:25 Message: Logged In: YES user_id=878033 I uploaded both the config.log and the pyconfig.h for 2.2.3. I'm curious what you think of it. The system is quite old, indeed (but we have even older among our customer base, as they are not very much inclined to investing in hardware!). It is much used, though. Regards, Roger ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 18:19 Message: Logged In: YES user_id=6656 Can you attach the config.log for 2.2.3? I'm now a little curious as to how dynamic linking ever worked on this system (which is fairly old, right?) ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-01 17:45 Message: Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 17:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Fri Oct 3 09:28:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 09:28:32 2003 Subject: [Python-bugs-list] [ python-Bugs-815999 ] ImportError: No module named _socket Message-ID: Bugs item #815999, was opened at 2003-10-01 19:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peter Stauffert (stauffert) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named _socket Initial Comment: Hi There is a problem during the installation of python 2.3.1: I used configure with the following options: ./configure --enable-shared=yes --with-signal- module=yes --with-cxx=/usr/freeware/bin/c++ make runs to the end, only warning messages are displayed. Running "make test" on a SGI Origin200, IRIX 6.5-18 I got the following error message: test test___all__ failed -- Traceback (most recent call last): File "/install/fw/Python-2.3.1/Lib/test/test___all__.py", line 54, in test_all import _socket ImportError: No module named _socket This looks like the python bug 565710 reported for python 2.2.1 which was solved by modifications of setup.py in the top level directory. But setup.py was modified in python 2.3.1 and I could not apply the old patch to the new version. Could you help me with this problem? Thanks a lot Peter Stauffert ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:28 Message: Logged In: YES user_id=21627 Can you please attach the build log? In particular, it would be importing to see whether building _socket was attempted, and failed. Maybe your compiler just doesn't work??? ---------------------------------------------------------------------- Comment By: casey dunn (caseyd) Date: 2003-10-01 21:53 Message: Logged In: YES user_id=878394 I have seen this on Solaris as well, recent and old vintages. Casey Dunn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 From noreply at sourceforge.net Fri Oct 3 09:30:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 09:30:30 2003 Subject: [Python-bugs-list] [ python-Bugs-817156 ] invalid \U escape gives 0=length unistr Message-ID: Bugs item #817156, was opened at 2003-10-03 08: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=817156&group_id=5470 Category: Unicode Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: M.-A. Lemburg (lemburg) Summary: invalid \U escape gives 0=length unistr Initial Comment: >>> u'\Ufffffffe' # CORRECT UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character >>> u'\Uffffffff' # WRONG u'' >>> len(_) 0 Observed on 2.2.2 (redhat wide-unicode build, sys.maxunicode=1114111), 2.3.1 (custom build, sys.maxunicode == 65535) I think the problem is due to this logic in unicodeobject.c:PyUnicode_DecodeUnicodeEscape() if (chr == 0xffffffff) /* _decoding_error will have already written into the target buffer. */ break; perhaps it should be (chr == 0xffffffff && PyErr_Occurred()) I tried this change locally, and it fixes the problem: >>> u'\Uffffffff' UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character >>> u'\Ufffffffe' UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character and doesn't change the outcome of the test suite. Patch against 2.3.1 attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817156&group_id=5470 From noreply at sourceforge.net Fri Oct 3 09:30:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 09:30:56 2003 Subject: [Python-bugs-list] [ python-Bugs-815668 ] test_locale and en_US Message-ID: Bugs item #815668, was opened at 2003-10-01 09:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815668&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: test_locale and en_US Initial Comment: Is it worth making test_locale try first "en_US", then "C", as locale names? None of the systems I've tried have "en_US" as a valid locale. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:30 Message: Logged In: YES user_id=21627 That would be incorrect. The test whether there is grouping in numeric formatting. However, in the C locale, there is no grouping. Most systems should have an English locale - it might have a different name, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815668&group_id=5470 From noreply at sourceforge.net Fri Oct 3 09:33:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 09:33:32 2003 Subject: [Python-bugs-list] [ python-Bugs-814726 ] RedHat 9 blows up at dlclose of pyexpat.so Message-ID: Bugs item #814726, was opened at 2003-09-29 22:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: RedHat 9 blows up at dlclose of pyexpat.so Initial Comment: With python 2.3, built with GCC 3.2. With RedHat 9.0 ... glibc-2.3.2-27.9 With python linked into the application as a shared library... a SIGSEGV at exit. Perhaps the modules should be marked -z nodelete to duck this latest incarnation of an old familiar glibc bug? atexit: (gdb) where #0 0x42073771 in free () from /lib/tls/libc.so.6 #1 0x420ebd8e in __unregister_atfork () from /lib/tls/libc.so.6 #2 0x42029fb8 in __cxa_finalize () from /lib/tls/libc.so.6 #3 0x41fd19fc in __do_global_dtors_aux () from /vobs/rex/bin_g/RH72-gcc-3.2/python/pyexpat.so #4 0x41fef3a9 in _fini () from /vobs/rex/bin_g/RH72- gcc-3.2/python/pyexpat.so #5 0x4000ce44 in _dl_fini () from /lib/ld-linux.so.2 #6 0x42029d40 in exit () from /lib/tls/libc.so.6 #7 0x42015708 in __libc_start_main () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:33 Message: Logged In: YES user_id=21627 This sounds like a bug in the system to me, not a bug in Python. Maybe it can be worked-around by not building Python with g++? Maybe it can be worked-around by not using buggy TLS implementations? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 From noreply at sourceforge.net Fri Oct 3 09:35:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 09:35:55 2003 Subject: [Python-bugs-list] [ python-Bugs-814544 ] AIX configure;make fails Message-ID: Bugs item #814544, was opened at 2003-09-29 18:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814544&group_id=5470 Category: Build >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: John Ruttenberg (rutt) Assigned to: Nobody/Anonymous (nobody) Summary: AIX configure;make fails Initial Comment: Standard ./configure and make fails for me with both 2.2.3 and 2.3.1 on AIX. On AIX-5.1 with IBM's visualage compiler installed the build fails with the following: ./Modules/ld_so_aix cc_r -bI:Modules/python.exp build/temp.aix-5.1-2.2/cryptmodule.o -L/usr/local/lib -lcrypt -o \ build/lib.aix-5.1-2.2/crypt.so building '_socket' extension cc_r -DNDEBUG -O -DUSE_SSL=1 -I/usr/local/ssl/include -I. -I/home/rutt/src/Python-2.2.3/./Include -I/usr/local/in\ clude -I/home/rutt/src/Python-2.2.3/Include -I/home/rutt/src/Python-2.2.3 -c /home/rutt/src/Python-2.2.3/Modules/\ socketmodule.c -o build/temp.aix-5.1-2.2/socketmodule.o ./Modules/ld_so_aix cc_r -bI:Modules/python.exp build/temp.aix-5.1-2.2/socketmodule.o -L/usr/local/ssl/lib -L/usr\ /local/lib -lssl -lcrypto -o build/lib.aix-5.1-2.2/_socket.so ld: 0711-317 ERROR: Undefined symbol: .__umoddi3 ld: 0711-317 ERROR: Undefined symbol: .__udivdi3 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. *** WARNING: renaming "_socket" since importing it failed: from module build/lib.aix-5.1-2.2/_socket.so No such f\ ile or directory error: No such file or directory make: *** [sharedmods] Error 1 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:35 Message: Logged In: YES user_id=21627 As yet another alternative: build the socket module without SSL, by editing Modules/Setup. There is no bug in Python here AFAICT, so closing this as third-party. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 18:08 Message: Logged In: YES user_id=29957 Aha! Those missing symbols are from libgcc.a. So, it looks like the SSL libraries in /usr/local/lib were built with gcc, while you're trying to link them with the IBM compiler. A couple of approaches you could try: Build both Python and the OpenSSL libraries with the same compiler (either GCC or IBM's) Try adding -lgcc (plus the appropriate -L line to where-ever gcc has stashed it - usually somewhere like /usr/local/lib/gcc-lib//version/) to the end of the link line for socketmodule.so ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:58 Message: Logged In: YES user_id=29957 Hm. Could it be that socketmodule needs to be linked with libm on this platform? If you try the link stage of the code by hand, and add -lm after -lcrypto, does it help? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814544&group_id=5470 From noreply at sourceforge.net Fri Oct 3 09:37:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 09:37:14 2003 Subject: [Python-bugs-list] [ python-Bugs-814524 ] libpython2.3.so.1.0 can't be found with -l Message-ID: Bugs item #814524, was opened at 2003-09-29 17:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814524&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: libpython2.3.so.1.0 can't be found with -l Initial Comment: The linux 'ld' does not know how to find libpython2.3.so.1.0. The convention here is to add a symbolic link named 'libpython2.3.so' for use at link time, and then the use of the SONAME option causes the dynamic linker to search for the longer name at runtime. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:37 Message: Logged In: YES user_id=21627 This is fixed in 2.3.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814524&group_id=5470 From noreply at sourceforge.net Fri Oct 3 09:37:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 09:37:33 2003 Subject: [Python-bugs-list] [ python-Bugs-814726 ] RedHat 9 blows up at dlclose of pyexpat.so Message-ID: Bugs item #814726, was opened at 2003-09-29 16:55 Message generated for change (Comment added) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: RedHat 9 blows up at dlclose of pyexpat.so Initial Comment: With python 2.3, built with GCC 3.2. With RedHat 9.0 ... glibc-2.3.2-27.9 With python linked into the application as a shared library... a SIGSEGV at exit. Perhaps the modules should be marked -z nodelete to duck this latest incarnation of an old familiar glibc bug? atexit: (gdb) where #0 0x42073771 in free () from /lib/tls/libc.so.6 #1 0x420ebd8e in __unregister_atfork () from /lib/tls/libc.so.6 #2 0x42029fb8 in __cxa_finalize () from /lib/tls/libc.so.6 #3 0x41fd19fc in __do_global_dtors_aux () from /vobs/rex/bin_g/RH72-gcc-3.2/python/pyexpat.so #4 0x41fef3a9 in _fini () from /vobs/rex/bin_g/RH72- gcc-3.2/python/pyexpat.so #5 0x4000ce44 in _dl_fini () from /lib/ld-linux.so.2 #6 0x42029d40 in exit () from /lib/tls/libc.so.6 #7 0x42015708 in __libc_start_main () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- >Comment By: benson margulies (benson_basis) Date: 2003-10-03 09:37 Message: Logged In: YES user_id=876734 If this is a system bug, it's a glibc bug, not a gcc bug. So avoiding gcc won't help. RedHat/glibc have a very bad track record of exploding when dlclosing C++ shared libraries. They've had many bugs of this form. If pyexpat has to have C++ code, it should be coded with no static constructor usage to avoid this problem, and similiar problems that might arise other places. TLS isn't in action. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 09:33 Message: Logged In: YES user_id=21627 This sounds like a bug in the system to me, not a bug in Python. Maybe it can be worked-around by not building Python with g++? Maybe it can be worked-around by not using buggy TLS implementations? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 From noreply at sourceforge.net Fri Oct 3 09:37:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 09:37:36 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 11:31 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Martin v. L?wis (loewis) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-03 14:37 Message: Logged In: YES user_id=6656 Agree that would be nice, but how do you do arrange for that for the tests run by, e.g., AC_CHECK_FUNCS? Seems to me you have to add it to CFLAGS to make that happen... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 14:26 Message: Logged In: YES user_id=21627 I agree it is a hack. Without testing anything right know, I think all configure tests should run with BASECFLAGS. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 13:49 Message: Logged In: YES user_id=6656 Glad to have my suspicions confirmed! The reason my patch was a hack is that it patches up SCO ok, but this is at least potentially a problem on other platforms. Given the lack of similar bug reports, though, perhaps it isn't. The remaining warnings look like different issues; should they become bothering I recommend opening new reports. Assigning to Martin, 'cause I'd like him to read my comment of 2003-10-03 12:17 before I check anything in (we missed 2.3.2, and I don't think 2.3.3 will be for a while). ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-03 13:37 Message: Logged In: YES user_id=878033 Hi Michael, nice hack for a first time: no warnings this time, as you can see in the attached make.out. Thanks a lot! Only a few compiler errors remain, but I cannot be bothered with them right now. So just FYI (after running make; make clean): >make > make.out "Objects/stringobject.c", line 1765: warning: statement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/getaddrinfo.c", line 556: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/getnameinfo.c", line 184: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2374: error: undefi ned symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2972: error: undefi ned symbol: AF_INET6 "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: undefi ned symbol: INET_ADDRSTRLEN "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: integr al constant expression expected "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3055: warning: stat ement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1553: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1554: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1964: warning: ass ignment type mismatch ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 12:17 Message: Logged In: YES user_id=6656 Curioser and curioser. The difference seems to be that configure for 2.2.3 passes "-belf" to cc when checking for dlopen but configure for 2.3 doesn't. I actually have an idea how this happens: in 2.3, the CFLAGS variable was split up into BASECFLAGS and OPT. We know we need -belf on SCO, so we stuff that into BASECFLAGS. However, this *doesn't* make the rest of the configure tests use -belf -- result breakage. (Martin, are you reading this? Does this sound reasonable?) Roger, can you try the attached patch? It's a bit of a hack... ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-02 23:25 Message: Logged In: YES user_id=878033 I uploaded both the config.log and the pyconfig.h for 2.2.3. I'm curious what you think of it. The system is quite old, indeed (but we have even older among our customer base, as they are not very much inclined to investing in hardware!). It is much used, though. Regards, Roger ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 17:19 Message: Logged In: YES user_id=6656 Can you attach the config.log for 2.2.3? I'm now a little curious as to how dynamic linking ever worked on this system (which is fairly old, right?) ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-01 16:45 Message: Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 16:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 15:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Fri Oct 3 09:54:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 09:54:54 2003 Subject: [Python-bugs-list] [ python-Bugs-817178 ] Email.message example missing arg Message-ID: Bugs item #817178, was opened at 2003-10-03 09: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=817178&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: Nobody/Anonymous (nobody) Summary: Email.message example missing arg Initial Comment: LIb Ref 12.2.3 Generating MIME documents says ''' class Generator( outfp[, mangle_from_[, maxheaderlen]]) The constructor for the Generator class takes a file-like object called outfp for an argument. outfp must support the write() method and be usable as the output file in a Python extended print statement. ''' 12.2.1 Representing an email message has example ''' from cStringIO import StringIO from email.Generator import Generator fp = StringIO() g = Generator(mangle_from_=False, maxheaderlen=60) ... ''' It seems prett clear that fp should be added as first arg of Generator call. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817178&group_id=5470 From noreply at sourceforge.net Fri Oct 3 10:09:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 10:09:44 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 12:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Martin v. L?wis (loewis) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 16:09 Message: Logged In: YES user_id=21627 Yes, setting CFLAGS appears to be the only way to achieve that. There is also the issue of the user setting CFLAGS before configure starts; traditionally, these should get incorporated into both configure tests, and the final build process. So something like # early BASECFLAGS=$CFLAGS # after each block changing either BASECFLAGS or OPT CFLAGS=$BASECFLAGS $OPT might work (unless the user selects a flag that contradicts with one set in BASECFLAGS) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 15:37 Message: Logged In: YES user_id=6656 Agree that would be nice, but how do you do arrange for that for the tests run by, e.g., AC_CHECK_FUNCS? Seems to me you have to add it to CFLAGS to make that happen... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:26 Message: Logged In: YES user_id=21627 I agree it is a hack. Without testing anything right know, I think all configure tests should run with BASECFLAGS. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 14:49 Message: Logged In: YES user_id=6656 Glad to have my suspicions confirmed! The reason my patch was a hack is that it patches up SCO ok, but this is at least potentially a problem on other platforms. Given the lack of similar bug reports, though, perhaps it isn't. The remaining warnings look like different issues; should they become bothering I recommend opening new reports. Assigning to Martin, 'cause I'd like him to read my comment of 2003-10-03 12:17 before I check anything in (we missed 2.3.2, and I don't think 2.3.3 will be for a while). ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-03 14:37 Message: Logged In: YES user_id=878033 Hi Michael, nice hack for a first time: no warnings this time, as you can see in the attached make.out. Thanks a lot! Only a few compiler errors remain, but I cannot be bothered with them right now. So just FYI (after running make; make clean): >make > make.out "Objects/stringobject.c", line 1765: warning: statement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/getaddrinfo.c", line 556: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/getnameinfo.c", line 184: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2374: error: undefi ned symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2972: error: undefi ned symbol: AF_INET6 "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: undefi ned symbol: INET_ADDRSTRLEN "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: integr al constant expression expected "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3055: warning: stat ement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1553: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1554: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1964: warning: ass ignment type mismatch ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 13:17 Message: Logged In: YES user_id=6656 Curioser and curioser. The difference seems to be that configure for 2.2.3 passes "-belf" to cc when checking for dlopen but configure for 2.3 doesn't. I actually have an idea how this happens: in 2.3, the CFLAGS variable was split up into BASECFLAGS and OPT. We know we need -belf on SCO, so we stuff that into BASECFLAGS. However, this *doesn't* make the rest of the configure tests use -belf -- result breakage. (Martin, are you reading this? Does this sound reasonable?) Roger, can you try the attached patch? It's a bit of a hack... ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-03 00:25 Message: Logged In: YES user_id=878033 I uploaded both the config.log and the pyconfig.h for 2.2.3. I'm curious what you think of it. The system is quite old, indeed (but we have even older among our customer base, as they are not very much inclined to investing in hardware!). It is much used, though. Regards, Roger ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 18:19 Message: Logged In: YES user_id=6656 Can you attach the config.log for 2.2.3? I'm now a little curious as to how dynamic linking ever worked on this system (which is fairly old, right?) ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-01 17:45 Message: Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 17:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Fri Oct 3 10:14:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 10:14:10 2003 Subject: [Python-bugs-list] [ python-Bugs-814726 ] RedHat 9 blows up at dlclose of pyexpat.so Message-ID: Bugs item #814726, was opened at 2003-09-29 22:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: RedHat 9 blows up at dlclose of pyexpat.so Initial Comment: With python 2.3, built with GCC 3.2. With RedHat 9.0 ... glibc-2.3.2-27.9 With python linked into the application as a shared library... a SIGSEGV at exit. Perhaps the modules should be marked -z nodelete to duck this latest incarnation of an old familiar glibc bug? atexit: (gdb) where #0 0x42073771 in free () from /lib/tls/libc.so.6 #1 0x420ebd8e in __unregister_atfork () from /lib/tls/libc.so.6 #2 0x42029fb8 in __cxa_finalize () from /lib/tls/libc.so.6 #3 0x41fd19fc in __do_global_dtors_aux () from /vobs/rex/bin_g/RH72-gcc-3.2/python/pyexpat.so #4 0x41fef3a9 in _fini () from /vobs/rex/bin_g/RH72- gcc-3.2/python/pyexpat.so #5 0x4000ce44 in _dl_fini () from /lib/ld-linux.so.2 #6 0x42029d40 in exit () from /lib/tls/libc.so.6 #7 0x42015708 in __libc_start_main () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 16:14 Message: Logged In: YES user_id=21627 I did not suggest to avoid gcc, but to avoid g++ (I'm only guessing here, since you haven't reported the build log, ldd output for pyexpat.so, or similar - but it might be that pyexpat.so was linked with g++, which would explain that it somehow calls __cxa_finalize). pyexpat itself has no C++ in it. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-03 15:37 Message: Logged In: YES user_id=876734 If this is a system bug, it's a glibc bug, not a gcc bug. So avoiding gcc won't help. RedHat/glibc have a very bad track record of exploding when dlclosing C++ shared libraries. They've had many bugs of this form. If pyexpat has to have C++ code, it should be coded with no static constructor usage to avoid this problem, and similiar problems that might arise other places. TLS isn't in action. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:33 Message: Logged In: YES user_id=21627 This sounds like a bug in the system to me, not a bug in Python. Maybe it can be worked-around by not building Python with g++? Maybe it can be worked-around by not using buggy TLS implementations? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 From noreply at sourceforge.net Fri Oct 3 10:15:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 10:15:53 2003 Subject: [Python-bugs-list] [ python-Bugs-814726 ] RedHat 9 blows up at dlclose of pyexpat.so Message-ID: Bugs item #814726, was opened at 2003-09-29 16:55 Message generated for change (Comment added) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: RedHat 9 blows up at dlclose of pyexpat.so Initial Comment: With python 2.3, built with GCC 3.2. With RedHat 9.0 ... glibc-2.3.2-27.9 With python linked into the application as a shared library... a SIGSEGV at exit. Perhaps the modules should be marked -z nodelete to duck this latest incarnation of an old familiar glibc bug? atexit: (gdb) where #0 0x42073771 in free () from /lib/tls/libc.so.6 #1 0x420ebd8e in __unregister_atfork () from /lib/tls/libc.so.6 #2 0x42029fb8 in __cxa_finalize () from /lib/tls/libc.so.6 #3 0x41fd19fc in __do_global_dtors_aux () from /vobs/rex/bin_g/RH72-gcc-3.2/python/pyexpat.so #4 0x41fef3a9 in _fini () from /vobs/rex/bin_g/RH72- gcc-3.2/python/pyexpat.so #5 0x4000ce44 in _dl_fini () from /lib/ld-linux.so.2 #6 0x42029d40 in exit () from /lib/tls/libc.so.6 #7 0x42015708 in __libc_start_main () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- >Comment By: benson margulies (benson_basis) Date: 2003-10-03 10:15 Message: Logged In: YES user_id=876734 I didn't realize that the decision to use g++ as the linker was one that we made here locally (I didn't do the build). We'll try avoiding it and see if things get better. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 10:14 Message: Logged In: YES user_id=21627 I did not suggest to avoid gcc, but to avoid g++ (I'm only guessing here, since you haven't reported the build log, ldd output for pyexpat.so, or similar - but it might be that pyexpat.so was linked with g++, which would explain that it somehow calls __cxa_finalize). pyexpat itself has no C++ in it. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-03 09:37 Message: Logged In: YES user_id=876734 If this is a system bug, it's a glibc bug, not a gcc bug. So avoiding gcc won't help. RedHat/glibc have a very bad track record of exploding when dlclosing C++ shared libraries. They've had many bugs of this form. If pyexpat has to have C++ code, it should be coded with no static constructor usage to avoid this problem, and similiar problems that might arise other places. TLS isn't in action. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 09:33 Message: Logged In: YES user_id=21627 This sounds like a bug in the system to me, not a bug in Python. Maybe it can be worked-around by not building Python with g++? Maybe it can be worked-around by not using buggy TLS implementations? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 From noreply at sourceforge.net Fri Oct 3 10:21:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 10:21:20 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 11:31 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Martin v. L?wis (loewis) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-03 15:20 Message: Logged In: YES user_id=6656 Something like the attached? It's impressively vile, but it doesn't seem to break anything on linux. I'm not quite sure what gyrations people expect this machinery to withstand, though... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:09 Message: Logged In: YES user_id=21627 Yes, setting CFLAGS appears to be the only way to achieve that. There is also the issue of the user setting CFLAGS before configure starts; traditionally, these should get incorporated into both configure tests, and the final build process. So something like # early BASECFLAGS=$CFLAGS # after each block changing either BASECFLAGS or OPT CFLAGS=$BASECFLAGS $OPT might work (unless the user selects a flag that contradicts with one set in BASECFLAGS) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 14:37 Message: Logged In: YES user_id=6656 Agree that would be nice, but how do you do arrange for that for the tests run by, e.g., AC_CHECK_FUNCS? Seems to me you have to add it to CFLAGS to make that happen... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 14:26 Message: Logged In: YES user_id=21627 I agree it is a hack. Without testing anything right know, I think all configure tests should run with BASECFLAGS. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 13:49 Message: Logged In: YES user_id=6656 Glad to have my suspicions confirmed! The reason my patch was a hack is that it patches up SCO ok, but this is at least potentially a problem on other platforms. Given the lack of similar bug reports, though, perhaps it isn't. The remaining warnings look like different issues; should they become bothering I recommend opening new reports. Assigning to Martin, 'cause I'd like him to read my comment of 2003-10-03 12:17 before I check anything in (we missed 2.3.2, and I don't think 2.3.3 will be for a while). ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-03 13:37 Message: Logged In: YES user_id=878033 Hi Michael, nice hack for a first time: no warnings this time, as you can see in the attached make.out. Thanks a lot! Only a few compiler errors remain, but I cannot be bothered with them right now. So just FYI (after running make; make clean): >make > make.out "Objects/stringobject.c", line 1765: warning: statement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/getaddrinfo.c", line 556: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/getnameinfo.c", line 184: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2374: error: undefi ned symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2972: error: undefi ned symbol: AF_INET6 "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: undefi ned symbol: INET_ADDRSTRLEN "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: integr al constant expression expected "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3055: warning: stat ement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1553: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1554: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1964: warning: ass ignment type mismatch ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 12:17 Message: Logged In: YES user_id=6656 Curioser and curioser. The difference seems to be that configure for 2.2.3 passes "-belf" to cc when checking for dlopen but configure for 2.3 doesn't. I actually have an idea how this happens: in 2.3, the CFLAGS variable was split up into BASECFLAGS and OPT. We know we need -belf on SCO, so we stuff that into BASECFLAGS. However, this *doesn't* make the rest of the configure tests use -belf -- result breakage. (Martin, are you reading this? Does this sound reasonable?) Roger, can you try the attached patch? It's a bit of a hack... ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-02 23:25 Message: Logged In: YES user_id=878033 I uploaded both the config.log and the pyconfig.h for 2.2.3. I'm curious what you think of it. The system is quite old, indeed (but we have even older among our customer base, as they are not very much inclined to investing in hardware!). It is much used, though. Regards, Roger ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 17:19 Message: Logged In: YES user_id=6656 Can you attach the config.log for 2.2.3? I'm now a little curious as to how dynamic linking ever worked on this system (which is fairly old, right?) ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-01 16:45 Message: Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 16:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 15:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Fri Oct 3 11:01:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 11:02:09 2003 Subject: [Python-bugs-list] [ python-Bugs-817234 ] re.finditer hangs on final empty match Message-ID: Bugs item #817234, was opened at 2003-10-03 09: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=817234&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin J. Butler (kevinbutler) Assigned to: Fredrik Lundh (effbot) Summary: re.finditer hangs on final empty match Initial Comment: The iterator returned by re.finditer appears to not terminate if the final match is empty, but rather keeps returning the final (empty) match. Is this a bug in _sre? If so, I'll be happy to file it, though fixing it is a bit beyond my _sre experience level at this point. The solution would appear to be to either a check for duplicate match in iterator.next(), or to increment position by one after returning an empty match (which should be OK, because if a non-empty match started at that location, we would have returned it instead of the empty match). Code to illustrate the failure: from re import finditer last = None for m in finditer( ".*", "asdf" ): if last == m.span(): print "duplicate match:", last break print m.group(), m.span() last = m.span() --- asdf (0, 4) (4, 4) duplicate match: (4, 4) --- findall works: print re.findall( ".*", "asdf" ) ['asdf', ''] Workaround is to explicitly check for a duplicate span, as I did above, or to check for a duplicate end(), which avoids the final empty match Seo Sanghyeon sent the following fix to python-dev list: Attached one line patch fixes re.finditer bug reported by Kevin J. Butler. I read cvs log to find out why this code is introduced, and it seems to be related to SF bug #581080. But that bug didn't appear after my patch, so I wonder why it was introduced in the first place. It seems beyond my understanding. Please enlighten me. To test: #581080 import re list(re.finditer('\s', 'a b')) # expected: one item list # bug: hang #Kevin J. Butler import re list(re.finditer('.*', 'asdf')) # expected: two item list (?) # bug: hang Seo Sanghyeon -------------- next part -------------- ? patch Index: Modules/_sre.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/_sre.c,v retrieving revision 2.99 diff -c -r2.99 _sre.c *** Modules/_sre.c 26 Jun 2003 14:41:08 -0000 2.99 --- Modules/_sre.c 2 Oct 2003 03:48:55 -0000 *************** *** 3062,3069 **** match = pattern_new_match((PatternObject*) self->pattern, state, status); ! if ((status == 0 || state->ptr == state->start) && ! state->ptr < state->end) state->start = (void*) ((char*) state->ptr + state->charsize); else state->start = state->ptr; --- 3062,3068 ---- match = pattern_new_match((PatternObject*) self->pattern, state, status); ! if (status == 0 || state->ptr == state->start) state->start = (void*) ((char*) state->ptr + state->charsize); else state->start = state->ptr; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817234&group_id=5470 From noreply at sourceforge.net Fri Oct 3 13:12:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 13:13:05 2003 Subject: [Python-bugs-list] [ python-Bugs-807314 ] Crash if getvar of a non-existent Tcl variable Message-ID: Bugs item #807314, was opened at 2003-09-16 20:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807314&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: David Ascher (david_ascher) Assigned to: Martin v. L?wis (loewis) Summary: Crash if getvar of a non-existent Tcl variable Initial Comment: In 2.3, the code: from Tkinter import * x = Tk() x.getvar('foobar') will crash. This is due to bad error checking in _tkinter.c, in the GetVar() code. A possible patch is attached. Making p7 because it's a crasher. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 19:12 Message: Logged In: YES user_id=21627 Fixed in NEWS 1.831.4.59 _tkinter.c 1.161.8.1,1.162 ---------------------------------------------------------------------- Comment By: David Ascher (david_ascher) Date: 2003-09-22 20:56 Message: Logged In: YES user_id=6114 Sorry, I'm afraid I'll have no time to apply before 2.3.1. -- if you do, please apply it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-18 20:01 Message: Logged In: YES user_id=21627 The patch is fine; please apply (or reassign if you want me to apply it). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807314&group_id=5470 From noreply at sourceforge.net Fri Oct 3 13:22:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 13:22:47 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 12:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) >Assigned to: Michael Hudson (mwh) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 19:22 Message: Logged In: YES user_id=21627 eurosys, can you confirm that config-hack-2.diff fixes your problem as well? I recommend integration of that change in both 2.4 and 2.3; if it causes problems on some system, we should have time before 2.3.3 to correct them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 16:20 Message: Logged In: YES user_id=6656 Something like the attached? It's impressively vile, but it doesn't seem to break anything on linux. I'm not quite sure what gyrations people expect this machinery to withstand, though... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 16:09 Message: Logged In: YES user_id=21627 Yes, setting CFLAGS appears to be the only way to achieve that. There is also the issue of the user setting CFLAGS before configure starts; traditionally, these should get incorporated into both configure tests, and the final build process. So something like # early BASECFLAGS=$CFLAGS # after each block changing either BASECFLAGS or OPT CFLAGS=$BASECFLAGS $OPT might work (unless the user selects a flag that contradicts with one set in BASECFLAGS) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 15:37 Message: Logged In: YES user_id=6656 Agree that would be nice, but how do you do arrange for that for the tests run by, e.g., AC_CHECK_FUNCS? Seems to me you have to add it to CFLAGS to make that happen... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:26 Message: Logged In: YES user_id=21627 I agree it is a hack. Without testing anything right know, I think all configure tests should run with BASECFLAGS. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 14:49 Message: Logged In: YES user_id=6656 Glad to have my suspicions confirmed! The reason my patch was a hack is that it patches up SCO ok, but this is at least potentially a problem on other platforms. Given the lack of similar bug reports, though, perhaps it isn't. The remaining warnings look like different issues; should they become bothering I recommend opening new reports. Assigning to Martin, 'cause I'd like him to read my comment of 2003-10-03 12:17 before I check anything in (we missed 2.3.2, and I don't think 2.3.3 will be for a while). ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-03 14:37 Message: Logged In: YES user_id=878033 Hi Michael, nice hack for a first time: no warnings this time, as you can see in the attached make.out. Thanks a lot! Only a few compiler errors remain, but I cannot be bothered with them right now. So just FYI (after running make; make clean): >make > make.out "Objects/stringobject.c", line 1765: warning: statement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/getaddrinfo.c", line 556: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/getnameinfo.c", line 184: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2374: error: undefi ned symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2972: error: undefi ned symbol: AF_INET6 "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: undefi ned symbol: INET_ADDRSTRLEN "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: integr al constant expression expected "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3055: warning: stat ement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1553: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1554: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1964: warning: ass ignment type mismatch ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 13:17 Message: Logged In: YES user_id=6656 Curioser and curioser. The difference seems to be that configure for 2.2.3 passes "-belf" to cc when checking for dlopen but configure for 2.3 doesn't. I actually have an idea how this happens: in 2.3, the CFLAGS variable was split up into BASECFLAGS and OPT. We know we need -belf on SCO, so we stuff that into BASECFLAGS. However, this *doesn't* make the rest of the configure tests use -belf -- result breakage. (Martin, are you reading this? Does this sound reasonable?) Roger, can you try the attached patch? It's a bit of a hack... ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-03 00:25 Message: Logged In: YES user_id=878033 I uploaded both the config.log and the pyconfig.h for 2.2.3. I'm curious what you think of it. The system is quite old, indeed (but we have even older among our customer base, as they are not very much inclined to investing in hardware!). It is much used, though. Regards, Roger ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 18:19 Message: Logged In: YES user_id=6656 Can you attach the config.log for 2.2.3? I'm now a little curious as to how dynamic linking ever worked on this system (which is fairly old, right?) ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-01 17:45 Message: Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 17:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Fri Oct 3 14:16:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 14:16:18 2003 Subject: [Python-bugs-list] [ python-Bugs-817234 ] re.finditer hangs on final empty match Message-ID: Bugs item #817234, was opened at 2003-10-03 09:01 Message generated for change (Comment added) made by kevinbutler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817234&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin J. Butler (kevinbutler) Assigned to: Fredrik Lundh (effbot) Summary: re.finditer hangs on final empty match Initial Comment: The iterator returned by re.finditer appears to not terminate if the final match is empty, but rather keeps returning the final (empty) match. Is this a bug in _sre? If so, I'll be happy to file it, though fixing it is a bit beyond my _sre experience level at this point. The solution would appear to be to either a check for duplicate match in iterator.next(), or to increment position by one after returning an empty match (which should be OK, because if a non-empty match started at that location, we would have returned it instead of the empty match). Code to illustrate the failure: from re import finditer last = None for m in finditer( ".*", "asdf" ): if last == m.span(): print "duplicate match:", last break print m.group(), m.span() last = m.span() --- asdf (0, 4) (4, 4) duplicate match: (4, 4) --- findall works: print re.findall( ".*", "asdf" ) ['asdf', ''] Workaround is to explicitly check for a duplicate span, as I did above, or to check for a duplicate end(), which avoids the final empty match Seo Sanghyeon sent the following fix to python-dev list: Attached one line patch fixes re.finditer bug reported by Kevin J. Butler. I read cvs log to find out why this code is introduced, and it seems to be related to SF bug #581080. But that bug didn't appear after my patch, so I wonder why it was introduced in the first place. It seems beyond my understanding. Please enlighten me. To test: #581080 import re list(re.finditer('\s', 'a b')) # expected: one item list # bug: hang #Kevin J. Butler import re list(re.finditer('.*', 'asdf')) # expected: two item list (?) # bug: hang Seo Sanghyeon -------------- next part -------------- ? patch Index: Modules/_sre.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Modules/_sre.c,v retrieving revision 2.99 diff -c -r2.99 _sre.c *** Modules/_sre.c 26 Jun 2003 14:41:08 -0000 2.99 --- Modules/_sre.c 2 Oct 2003 03:48:55 -0000 *************** *** 3062,3069 **** match = pattern_new_match((PatternObject*) self->pattern, state, status); ! if ((status == 0 || state->ptr == state->start) && ! state->ptr < state->end) state->start = (void*) ((char*) state->ptr + state->charsize); else state->start = state->ptr; --- 3062,3068 ---- match = pattern_new_match((PatternObject*) self->pattern, state, status); ! if (status == 0 || state->ptr == state->start) state->start = (void*) ((char*) state->ptr + state->charsize); else state->start = state->ptr; ---------------------------------------------------------------------- >Comment By: Kevin J. Butler (kevinbutler) Date: 2003-10-03 12:16 Message: Logged In: YES user_id=117665 The above patch does resolve the problem. The code was introduced in rev 2.85 http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/_sre.c to resolve bug 581080 http://sourceforge.net/tracker/index.php?func=detail&aid=581080&group_id=5470&atid=105470 but removing this line does not re-introduce that bug. Thanks, and kudos to Seo... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817234&group_id=5470 From noreply at sourceforge.net Fri Oct 3 16:34:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 16:34:57 2003 Subject: [Python-bugs-list] [ python-Bugs-817407 ] string.capitalize() broken? Message-ID: Bugs item #817407, was opened at 2003-10-03 20:34 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=817407&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Cliff Resnick (cresny) Assigned to: Nobody/Anonymous (nobody) Summary: string.capitalize() broken? Initial Comment: string.capitalize is capitalizing first character and lowercasing all following characters (as with 'title'), not just capitalizing first char. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817407&group_id=5470 From noreply at sourceforge.net Fri Oct 3 17:16:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 17:16:58 2003 Subject: [Python-bugs-list] [ python-Bugs-817407 ] string.capitalize() broken? Message-ID: Bugs item #817407, was opened at 2003-10-03 15:34 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817407&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Cliff Resnick (cresny) Assigned to: Nobody/Anonymous (nobody) Summary: string.capitalize() broken? Initial Comment: string.capitalize is capitalizing first character and lowercasing all following characters (as with 'title'), not just capitalizing first char. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-03 16:16 Message: Logged In: YES user_id=139865 Python 2.3.2 (#1, Oct 3 2003, 15:28:48) [GCC 3.3.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> help(''.capitalize) Help on built-in function capitalize: capitalize(...) S.capitalize() -> string Return a copy of the string S with *only* its first character capitalized. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817407&group_id=5470 From noreply at sourceforge.net Fri Oct 3 20:24:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 20:24:59 2003 Subject: [Python-bugs-list] [ python-Bugs-815999 ] ImportError: No module named _socket Message-ID: Bugs item #815999, was opened at 2003-10-02 03:21 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peter Stauffert (stauffert) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named _socket Initial Comment: Hi There is a problem during the installation of python 2.3.1: I used configure with the following options: ./configure --enable-shared=yes --with-signal- module=yes --with-cxx=/usr/freeware/bin/c++ make runs to the end, only warning messages are displayed. Running "make test" on a SGI Origin200, IRIX 6.5-18 I got the following error message: test test___all__ failed -- Traceback (most recent call last): File "/install/fw/Python-2.3.1/Lib/test/test___all__.py", line 54, in test_all import _socket ImportError: No module named _socket This looks like the python bug 565710 reported for python 2.2.1 which was solved by modifications of setup.py in the top level directory. But setup.py was modified in python 2.3.1 and I could not apply the old patch to the new version. Could you help me with this problem? Thanks a lot Peter Stauffert ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-04 10:24 Message: Logged In: YES user_id=29957 Does the patch available from www.python.org/bugs.html fix this problem? Which compiler did you use? From the configure line, above, it looks like you might be using gcc? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 23:28 Message: Logged In: YES user_id=21627 Can you please attach the build log? In particular, it would be importing to see whether building _socket was attempted, and failed. Maybe your compiler just doesn't work??? ---------------------------------------------------------------------- Comment By: casey dunn (caseyd) Date: 2003-10-02 05:53 Message: Logged In: YES user_id=878394 I have seen this on Solaris as well, recent and old vintages. Casey Dunn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 From noreply at sourceforge.net Fri Oct 3 20:26:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 20:27:00 2003 Subject: [Python-bugs-list] [ python-Bugs-814726 ] RedHat 9 blows up at dlclose of pyexpat.so Message-ID: Bugs item #814726, was opened at 2003-09-30 06:55 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: RedHat 9 blows up at dlclose of pyexpat.so Initial Comment: With python 2.3, built with GCC 3.2. With RedHat 9.0 ... glibc-2.3.2-27.9 With python linked into the application as a shared library... a SIGSEGV at exit. Perhaps the modules should be marked -z nodelete to duck this latest incarnation of an old familiar glibc bug? atexit: (gdb) where #0 0x42073771 in free () from /lib/tls/libc.so.6 #1 0x420ebd8e in __unregister_atfork () from /lib/tls/libc.so.6 #2 0x42029fb8 in __cxa_finalize () from /lib/tls/libc.so.6 #3 0x41fd19fc in __do_global_dtors_aux () from /vobs/rex/bin_g/RH72-gcc-3.2/python/pyexpat.so #4 0x41fef3a9 in _fini () from /vobs/rex/bin_g/RH72- gcc-3.2/python/pyexpat.so #5 0x4000ce44 in _dl_fini () from /lib/ld-linux.so.2 #6 0x42029d40 in exit () from /lib/tls/libc.so.6 #7 0x42015708 in __libc_start_main () from /lib/tls/libc.so.6 ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-04 10:26 Message: Logged In: YES user_id=29957 configure --without-cxx is the magic you probably want. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-04 00:15 Message: Logged In: YES user_id=876734 I didn't realize that the decision to use g++ as the linker was one that we made here locally (I didn't do the build). We'll try avoiding it and see if things get better. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-04 00:14 Message: Logged In: YES user_id=21627 I did not suggest to avoid gcc, but to avoid g++ (I'm only guessing here, since you haven't reported the build log, ldd output for pyexpat.so, or similar - but it might be that pyexpat.so was linked with g++, which would explain that it somehow calls __cxa_finalize). pyexpat itself has no C++ in it. ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-03 23:37 Message: Logged In: YES user_id=876734 If this is a system bug, it's a glibc bug, not a gcc bug. So avoiding gcc won't help. RedHat/glibc have a very bad track record of exploding when dlclosing C++ shared libraries. They've had many bugs of this form. If pyexpat has to have C++ code, it should be coded with no static constructor usage to avoid this problem, and similiar problems that might arise other places. TLS isn't in action. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 23:33 Message: Logged In: YES user_id=21627 This sounds like a bug in the system to me, not a bug in Python. Maybe it can be worked-around by not building Python with g++? Maybe it can be worked-around by not using buggy TLS implementations? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814726&group_id=5470 From noreply at sourceforge.net Fri Oct 3 22:06:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 3 22:06:13 2003 Subject: [Python-bugs-list] [ python-Bugs-816946 ] Float Multiplication Message-ID: Bugs item #816946, was opened at 2003-10-02 22:09 Message generated for change (Comment added) made by vktor You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816946&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Open Resolution: Invalid Priority: 5 Submitted By: Victor Demaria (vktor) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Float Multiplication Initial Comment: Why (1.16 * 100) is not the same than (1.16 * 10 * 10)? I tried 1.16*100. also and it is = 115.99999999; but if I do 1.16*10*10 I get 116. Thanks.... ---------------------------------------------------------------------- >Comment By: Victor Demaria (vktor) Date: 2003-10-03 20:06 Message: Logged In: YES user_id=879316 This is not a bug. Binary floating point cannot represent decimal fractions exactly, so some rounding always occurs (even in Python 1.5.2). What changed is that Python 2.0 shows more precision than before in certain circumstances (repr() and the interactive prompt). You can use str() or print to get the old, rounded output: >>> print 0.1+0.1 0.2 >>> Follow the link for more information: http://www.python.org/doc/2.2.1/tut/node14.html ---------------------------------------------------------------------- Comment By: Victor Demaria (vktor) Date: 2003-10-03 20:06 Message: Logged In: YES user_id=879316 I'sorry, but I don't agree... Even 3.13 (3.1299999999999999) * 100 is 313 = like 3.13*10*10 (3.13*100=3.13*10*10) In this case 1.16*100 <> 1.16*10*10 Sorry again, but it is a huge difference when you do int (1.16*100)=115 or you do int(1.16*10*10)=116 Thanks... ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-10-03 01:48 Message: Logged In: YES user_id=38376 The answer to your question can be found in the Python tutorial, and has nothing to do with regular expressions: http://www.python.org/doc/tut/node14.html Please don't use the bug tracker to ask for help in the future; I suggest asking on comp.lang.python (for other help forums, see www.python.org). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816946&group_id=5470 From noreply at sourceforge.net Sat Oct 4 03:38:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 03:38:19 2003 Subject: [Python-bugs-list] [ python-Bugs-816476 ] Fatal Python error: GC object already tracked Message-ID: Bugs item #816476, was opened at 2003-10-02 20:42 Message generated for change (Settings changed) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Thorsten Henninger (thenninger) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python error: GC object already tracked Initial Comment: Fatal Python error: GC object already tracked OS: Windows 2000 Server (Service Pack 4) Python: 2.3.1 (#47) pycurl: 7.10.6 I got this Fatal Error while fetching Webpages with pycurl. I do not have any other addiotional information. This error is reproducible and did not occur with Python2.2. Please contact me, if you need further information ---------------------------------------------------------------------- Comment By: Thorsten Henninger (thenninger) Date: 2003-10-03 04:07 Message: Logged In: YES user_id=878819 thank you, that makes sense! i will notice pycurl and have a look in th pycurl source! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-03 02:25 Message: Logged In: YES user_id=31435 You should report this to the pycurl project. The specific error message you report is new in Python 2.3, doing a check for errnoneous usage of the Python C API. That check didn't exist in Python 2.2. While it's possible there's a previously unreported error in Python 2.3 here, it's much more likely that the problem is in pycurl's C code, and that the error there simply went undetected before Python 2.3, appearing to work by luck. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-02 20:51 Message: Logged In: YES user_id=6656 Why do you think this is a bug in Python and not pycurl? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 From noreply at sourceforge.net Sat Oct 4 03:39:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 03:39:55 2003 Subject: [Python-bugs-list] [ python-Bugs-814613 ] socketmodule.c fails build, INET_ADDRSTRLEN not defined Message-ID: Bugs item #814613, was opened at 2003-09-30 04:22 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814613&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Randy Davis (randydavis1) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c fails build, INET_ADDRSTRLEN not defined Initial Comment: Modules/socketmodule.c fails to built on IRIX 6.3 gcc 3.2.2 due to INET_ADDRSTRLEN not being defined. Adding an additional "#define INET_ADDRSTRLEN 16" outside of the #ifdef's fixes it (so the #ifdefs would seem to not be taking into account IRIX 6.3). Here's the error: building '_socket' extension gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes - shared -fno-strict-aliasing -I. - I/usr2/admin/src/dev/python-2.3.1/./Include - I/usr/local/include -I/usr2/admin/src/dev/python- 2.3.1/Include -I/usr2/admin/src/dev/python-2.3.1 - c /usr2/admin/src/dev/pyth on-2.3.1/Modules/socketmodule.c -o build/temp.irix-6.3- 2.3/socketmodule.o /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c: In function `socket_gethostname': /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:2319: warning: implicit declaration of function `gethostname' /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c: In function `socket_inet_ntop': /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: `INET_ADDRSTRLEN' undeclared (first use in this function) /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: (Each undeclared identifier is reported only once /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: for each function it appears in.) /usr2/admin/src/dev/python- 2.3.1/Modules/socketmodule.c:3016: warning: unused variable `ip' ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-04 17:39 Message: Logged In: YES user_id=29957 Fixed in socketmodule.c - the fix will be in 2.3.3 (and 2.4). For now, there's a patch available from www.python.org/2.3.2/bugs.html ---------------------------------------------------------------------- Comment By: Randy Davis (randydavis1) Date: 2003-10-02 05:44 Message: Logged In: YES user_id=876412 Testing for INET_ADDRSTRLEN defined in the header files: ----- $ find /usr/include /usr/local/include -type f -exec INET_ADDRSTRLEN {} /dev/null \; $ ----- Nope, INET_ADDRSTRLEN isn't defined anywhere under IRIX 6.3, nor in any of the gcc (etc) installed header files under /usr/local/include. (Thus, configuring with --disable- ipv6 didn't help, either). Concerning whether the SGI compiler does it also, I don't know - the SGI compiler is a licensed product and isn't licensed on this system (hence the use of gcc - but, gcc has successfully compiled over 44 open source packages so far, including samba and other network-related applications). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 01:51 Message: Logged In: YES user_id=29957 With my brain screwed on correctly, I can see that my previous comments weren't correct. I'm attaching a (brutal) patch that "fixes" the problem, but before I apply it, I'd like to know if the problem is just with gcc on Irix, or does it also break with the SGI compiler? This looks like a gcc bug, maybe... ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 19:03 Message: Logged In: YES user_id=29957 Hm. It looks we define INET_ADDRSTRLEN only if ENABLE_IPV6 is false. Looking on my Linux machine, if IPV6 is enabled, INET_ADDRSTRLEN is defined in netinet/in.h - can you see if it's available in any Irix header files? Alternately, try rerunning configure with --disable-ipv6. We could probably put an #ifndef INET_ADDRSTRLEN #define INET_ADDRSTRLEN 16 #endif in socketmodule.c, but this seems to me like the problem might be in the SGI headers... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814613&group_id=5470 From noreply at sourceforge.net Sat Oct 4 03:55:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 03:55:33 2003 Subject: [Python-bugs-list] [ python-Bugs-817407 ] string.capitalize() broken? Message-ID: Bugs item #817407, was opened at 2003-10-03 22:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817407&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Cliff Resnick (cresny) Assigned to: Nobody/Anonymous (nobody) Summary: string.capitalize() broken? Initial Comment: string.capitalize is capitalizing first character and lowercasing all following characters (as with 'title'), not just capitalizing first char. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-04 09:55 Message: Logged In: YES user_id=21627 As gaul explains, this is not a bug. Closing it as invalid. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-03 23:16 Message: Logged In: YES user_id=139865 Python 2.3.2 (#1, Oct 3 2003, 15:28:48) [GCC 3.3.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> help(''.capitalize) Help on built-in function capitalize: capitalize(...) S.capitalize() -> string Return a copy of the string S with *only* its first character capitalized. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817407&group_id=5470 From noreply at sourceforge.net Sat Oct 4 03:56:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 03:57:04 2003 Subject: [Python-bugs-list] [ python-Bugs-811028 ] configure: curses busted on Freebsd/Mac OSX Message-ID: Bugs item #811028, was opened at 2003-09-23 17:50 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Richard Jones (richard) >Assigned to: Anthony Baxter (anthonybaxter) Summary: configure: curses busted on Freebsd/Mac OSX Initial Comment: Anthony said to log this: checking ncurses.h presence... yes configure: WARNING: ncurses.h: present but cannot be compiled configure: WARNING: ncurses.h: check for missing prerequisite headers? configure: WARNING: ncurses.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug- autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## I'll attach the text of the report and the configure output too since I'm pretty sure the above won't be ligible once sf's tracker's finished with it. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-04 17:56 Message: Logged In: YES user_id=29957 Fixed in configure.in 1.438, 1.427.4.8; configure 1.428, 1.416.4.9 there's also a patch available from www.python.org/2.3.2/bugs.html for people who need it working on 2.3.2. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-10-03 06:48 Message: Logged In: YES user_id=45365 On Jaguar _XOPEN_SOURCE_EXTENDED is only used in curses.h and ncurses.h, and one other place defines it (httpd/ap_config.h). The other good news is that on Panther the problem doesn't exist. ---------------------------------------------------------------------- Comment By: Benno Rice (benno) Date: 2003-10-02 02:59 Message: Logged In: YES user_id=9925 There is a bug in FreeBSD's ncurses.h where it checks to see if a macro called __wchar_t is defined before attempting to typedef it's own wchar_t. This causes problems because __wchar_t (and wchar_t) exist, but __wchar_t is a typedef not a macro. This is solved by removing _XOPEN_SOURCE_EXTENDED which is what triggers this check. Removing _XOPEN_SOURCE_EXTENDED should have no other implications on FreeBSD. There is a patch that disables _XOPEN_SOURCE_EXTENDED for FreeBSD at http://jeamland.net/~benno/configure.in.diff ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 02:42 Message: Logged In: YES user_id=29957 Ok. Ripping out the line AC_DEFINE(_XOPEN_SOURCE_EXTENDED, 1, Define to activate Unix95-and-earlier features) from configure.in fixes the problem on FreeBSD. The only occurance of _XOPEN_SOURCE_EXTENDED in FreeBSD's headers is ncurses.h. FreeBSD will hopefully fix the bug in their headers to remove the problem in a future version of the code. Jack or Richard, can you see if _XOPEN_SOURCE_EXTENDED is used anywhere else on Mac OS X? If not, we could put a workaround in for Mac OS X and FreeBSD to not define the header. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-02 02:28 Message: Logged In: YES user_id=29957 Benno tells me that there's a patch for configure available at http://jeamland.net/~benno/configure.in.diff It'll fix FreeBSD, but not Mac OS X. Argh. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-10-02 01:04 Message: Logged In: YES user_id=45365 I've also seen this. I don't have the time to dive into this, but I think it has to do with gcc 3.3. I had just upgraded to gcc 3.3 from 3.1, and before the upgrade I never saw the problem. Is everyone who sees the problem using gcc 3.3, by any chance? If so then it's probably an incompatibility between curses.h and that compiler. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 18:52 Message: Logged In: YES user_id=29957 Unless a FreeBSD or Mac OS X expert can step forward in the next day and suggest a fix, this isn't going to be fixed for 2.3.2(final). I can't spend any more time on it. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-10-01 09:29 Message: Logged In: YES user_id=6405 The diagnosis on OS X is similar, and the trigger for defining wchar_t in stdlib.h is the absence of _ANSI_SOURCE. Making it not define _XOPEN_SOURCE_EXTENDED also fixes the compile as per your FreeBSD fix. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 00:24 Message: Logged In: YES user_id=29957 Looking into it a bit on FreeBSD: /usr/include/ncurses.h:236: conflicting types for `wchar_t' /usr/include/stdlib.h:58: previous declaration of `wchar_t' and poking around a bit I find that stdlib.h defines wchar_t as an 'int', while ncurses.h defines it as 'unsigned long'. This is on FreeBSD 4.8. Extracting the failing configure code and making it not define _XOPEN_EXTENDED_SOURCE makes the test succeed, but I have no idea if this is an appropriate fix. ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-27 18:36 Message: Logged In: YES user_id=6405 (I didn't mention it in the report, only to Anthony : this is on OSX) The patch doesn't alter the configure behaviour. I can't remember how to run the curses test - "make test" skips it (the curses module is built though). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-09-27 17:53 Message: Logged In: YES user_id=21627 Can you try the patch in python.org/sf/806800 ? ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2003-09-23 18:28 Message: Logged In: YES user_id=6405 "make test" also reports: test_curses test test_curses crashed -- _curses.error: curs_set() returned ERR ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-23 18:14 Message: Logged In: YES user_id=29957 creosote (which is a freebsd machine) also sees this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811028&group_id=5470 From noreply at sourceforge.net Sat Oct 4 03:58:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 03:59:04 2003 Subject: [Python-bugs-list] [ python-Bugs-816929 ] term.h present but cannot be compiled Message-ID: Bugs item #816929, was opened at 2003-10-03 05:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816929&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nicholas Hawthorn (nhawthorn) Assigned to: Nobody/Anonymous (nobody) Summary: term.h present but cannot be compiled Initial Comment: This report relates to building Python 2.3.1 on Irix 6.5. Here is stderr output from: configure --with-cxx=CC configure: WARNING: term.h: present but cannot be compiled configure: WARNING: term.h: check for missing prerequisite headers? configure: WARNING: term.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## I did submit a bug report -- they said the issue is known. "make" after this gave the following error, among others:- cc-1059 cc: ERROR File = /xlv4/med_psyc/nhn/py231/Python-2.3.1/Modules/termios.c , Line = 633 A function call is not allowed in a constant expression. {"CWERASE", CWERASE}, By experiment on a very short C program, term.h needs curses.h to be included before it, and will not compile correctly otherwise. This would give a number of errors. Thanks and best wishes! ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-04 09:58 Message: Logged In: YES user_id=21627 Even though I cannot fully understand your remarks, it appears that you are suggesting a solution. Can you perhaps produce a patch that fixes the problem? I am still uncertain what the bug in Python here is. In line 633, there is no function call, as far as I can see (although CWERASE might expand to a function call); so it seems more likely that this is a bug in CC or in the system header files, not in Python. As a work-around, just try compiling --without-cxx. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816929&group_id=5470 From noreply at sourceforge.net Sat Oct 4 04:01:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 04:02:04 2003 Subject: [Python-bugs-list] [ python-Bugs-815646 ] thread unsafe file objects cause crash Message-ID: Bugs item #815646, was opened at 2003-10-01 08:22 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815646&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jan Olderdissen (janixia) Assigned to: Nobody/Anonymous (nobody) Summary: thread unsafe file objects cause crash Initial Comment: Note: This may be a dupe or a generalization of 595601. Running below code snippet on 2.3.1 release and debug build on Windows 2000/XP a few times will inevitably lead to a crash. 2.2.2 also exhibits this behavior. The crashing code: ------------ import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f=open("tmp1", "w") f.seek (0, 0) thread.start_new_thread(worker, ()) thread.start_new_thread(worker, ()) while 1: pass ------------- The issue appears to be this (and similar) code sections from fileobject.c: Py_BEGIN_ALLOW_THREADS errno = 0; ret = _portable_fseek(f->f_fp, offset, whence); Py_END_ALLOW_THREADS Note that due to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS, f->f_fp can be set to NULL by file_close prior to entering _portable_fseek. Similar crashes can be observed with read, write and close itself when they are mixed with a concurrent close. Obviously, the offending python code is buggy and a lock should be used to prevent concurrent access to f. However, it seems unreasonable for Python to crash because of it. A mutex preventing concurrent access to the file object seems like a reasonable way to fix this. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-04 10:01 Message: Logged In: YES user_id=21627 janixia, don't worry about the formatting - this is partially SF's fault, too. Would you be interested in developing and testing a patch? I think it would be sufficient to move the f->f_fp access out of the GIL releasage. ---------------------------------------------------------------------- Comment By: Jan Olderdissen (janixia) Date: 2003-10-01 09:08 Message: Logged In: YES user_id=877914 My apologies for the mangled source. I suppose there isn't a way for me to remedy the situation. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 09:03 Message: Logged In: YES user_id=29957 Attaching the failing code as an attachment, because SF mangles source code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815646&group_id=5470 From noreply at sourceforge.net Sat Oct 4 04:03:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 04:03:44 2003 Subject: [Python-bugs-list] [ python-Bugs-814602 ] socket.gethostbyaddr('www.google.com') Message-ID: Bugs item #814602, was opened at 2003-09-29 20:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814602&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Gerd Schulz (spikeee) Assigned to: Nobody/Anonymous (nobody) Summary: socket.gethostbyaddr('www.google.com') Initial Comment: Results in error! ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-04 10:03 Message: Logged In: YES user_id=21627 Of course it results in an error! 'www.google.com' is not an IP number. Use socket.gethostbyname to resolve host names. Closing as invalid. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:44 Message: Logged In: YES user_id=29957 What platform? What compiler? What exact version of Python? What was the error? Does the same code work under an earlier version of Python? If so, which version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814602&group_id=5470 From noreply at sourceforge.net Sat Oct 4 04:04:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 04:04:31 2003 Subject: [Python-bugs-list] [ python-Bugs-813453 ] restrictions in _tkinter built with threaded tk undocumented Message-ID: Bugs item #813453, was opened at 2003-09-27 11:08 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813453&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Martin v. L?wis (loewis) Summary: restrictions in _tkinter built with threaded tk undocumented Initial Comment: Basically, raise some comments from the _tkinter.c module to the library reference: If Tcl is threaded, this approach won't work anymore. The Tcl interpreter is only valid in the thread that created it, and all Tk activity must happen in this thread, also. That means that the mainloop must be invoked in the thread that created the interpreter. Invoking commands from other threads is possible; _tkinter will queue an event for the interpreter thread, which will then execute the command and pass back the result. If the main thread is not in the mainloop, and invoking commands causes an exception; if the main loop is running but not processing events, the command invocation will block. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813453&group_id=5470 From noreply at sourceforge.net Sat Oct 4 04:06:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 04:06:41 2003 Subject: [Python-bugs-list] [ python-Bugs-813449 ] locale.getdefaultlocale doesnt handle all locales gracefully Message-ID: Bugs item #813449, was opened at 2003-09-27 10:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813449&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: locale.getdefaultlocale doesnt handle all locales gracefully Initial Comment: [forwarded from http://bugs.debian.org/185776] $ LC_ALL=en_ZA python Python 2.3.1 (#2, Sep 24 2003, 11:39:14) [GCC 3.3.2 20030908 (Debian prerelease)] 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: en_ZA Note that locale.getlocale correctly returns (None, None) locale.getdefaultlocale() calls _parse_localename, which throws a ValueError if normalize e.g. does not return an encoding. If this behaviour in python is "as it should be", locale.getdefaultlocale should document it as such, to make it clear to apps using getdefaultlocale that they *must indeed* handle such an exception gracefully. (In this case, it could probably be a "normal" bug, then the "important" bug belongs with apt-listchanges.) The problem might be (depending on "specifications") either getlocale returning ValueError in the "unknown" case, or it could be because locale_alias does not contain an entry for en_ZA... ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-04 10:06 Message: Logged In: YES user_id=21627 This is a known limitation: getdefaultlocale should not be used in new code. If the intention is to compute the locale's encoding, locale.getpreferredencoding should be used instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813449&group_id=5470 From noreply at sourceforge.net Sat Oct 4 04:52:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 04:52:19 2003 Subject: [Python-bugs-list] [ python-Bugs-814602 ] socket.gethostbyaddr('www.google.com') Message-ID: Bugs item #814602, was opened at 2003-09-29 20:09 Message generated for change (Comment added) made by spikeee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814602&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Gerd Schulz (spikeee) Assigned to: Nobody/Anonymous (nobody) Summary: socket.gethostbyaddr('www.google.com') Initial Comment: Results in error! ---------------------------------------------------------------------- >Comment By: Gerd Schulz (spikeee) Date: 2003-10-04 10:52 Message: Logged In: YES user_id=687873 Maybe it is not intended, but for all other domains I tested, it worked: >>> socket.gethostbyaddr('www.sf.net') ('sourceforge.net', ['203.250.35.66.in-addr.arpa'], ['66.35.250.203']) So that's some kind of inconsistence. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-04 10:03 Message: Logged In: YES user_id=21627 Of course it results in an error! 'www.google.com' is not an IP number. Use socket.gethostbyname to resolve host names. Closing as invalid. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:44 Message: Logged In: YES user_id=29957 What platform? What compiler? What exact version of Python? What was the error? Does the same code work under an earlier version of Python? If so, which version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814602&group_id=5470 From noreply at sourceforge.net Sat Oct 4 05:04:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 05:05:00 2003 Subject: [Python-bugs-list] [ python-Bugs-814602 ] socket.gethostbyaddr('www.google.com') Message-ID: Bugs item #814602, was opened at 2003-09-29 20:09 Message generated for change (Comment added) made by spikeee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814602&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Invalid >Priority: 9 Submitted By: Gerd Schulz (spikeee) Assigned to: Nobody/Anonymous (nobody) Summary: socket.gethostbyaddr('www.google.com') Initial Comment: Results in error! ---------------------------------------------------------------------- >Comment By: Gerd Schulz (spikeee) Date: 2003-10-04 11:04 Message: Logged In: YES user_id=687873 socket.gethostbyname('www.google.com') '216.239.39.99' >>> socket.gethostbyaddr('216.239.39.99') Traceback (most recent call last): File "", line 1, in ? herror: (11004, 'host not found') Google is killing this call, it has nothing to do with gethostbyaddr!!! ---------------------------------------------------------------------- Comment By: Gerd Schulz (spikeee) Date: 2003-10-04 10:52 Message: Logged In: YES user_id=687873 Maybe it is not intended, but for all other domains I tested, it worked: >>> socket.gethostbyaddr('www.sf.net') ('sourceforge.net', ['203.250.35.66.in-addr.arpa'], ['66.35.250.203']) So that's some kind of inconsistence. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-04 10:03 Message: Logged In: YES user_id=21627 Of course it results in an error! 'www.google.com' is not an IP number. Use socket.gethostbyname to resolve host names. Closing as invalid. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:44 Message: Logged In: YES user_id=29957 What platform? What compiler? What exact version of Python? What was the error? Does the same code work under an earlier version of Python? If so, which version? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814602&group_id=5470 From noreply at sourceforge.net Sat Oct 4 05:11:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 05:11:19 2003 Subject: [Python-bugs-list] [ python-Bugs-817611 ] Google kills socket lookup Message-ID: Bugs item #817611, was opened at 2003-10-04 11: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=817611&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerd Schulz (spikeee) Assigned to: Nobody/Anonymous (nobody) Summary: Google kills socket lookup Initial Comment: Just test: >>> socket.gethostbyname('www.google.com') '216.239.39.99' >>> socket.gethostbyaddr('216.239.39.99') Traceback (most recent call last): File "", line 1, in ? herror: (11004, 'host not found') Don't know why. Maybe of this strange akadns-stuff?!?! He struggles around for quite a time before he comes to the error, maybe to much or cyclic input. Cheers, Spikeee ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817611&group_id=5470 From noreply at sourceforge.net Sat Oct 4 11:26:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 11:26:39 2003 Subject: [Python-bugs-list] [ python-Bugs-817742 ] Need "new style note" Message-ID: Bugs item #817742, was opened at 2003-10-04 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=817742&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: Need "new style note" Initial Comment: When you split my patch into http://www.python.org/doc/current/ref/new-style- attribute-access.html and http://www.python.org/doc/current/ref/descriptors.html, the descriptors info doesn't say "new style classes only anymore" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817742&group_id=5470 From noreply at sourceforge.net Sat Oct 4 13:18:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 13:18:28 2003 Subject: [Python-bugs-list] [ python-Bugs-816476 ] Fatal Python error: GC object already tracked Message-ID: Bugs item #816476, was opened at 2003-10-02 06:42 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Open >Resolution: None Priority: 5 Submitted By: Thorsten Henninger (thenninger) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python error: GC object already tracked Initial Comment: Fatal Python error: GC object already tracked OS: Windows 2000 Server (Service Pack 4) Python: 2.3.1 (#47) pycurl: 7.10.6 I got this Fatal Error while fetching Webpages with pycurl. I do not have any other addiotional information. This error is reproducible and did not occur with Python2.2. Please contact me, if you need further information ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-04 13:18 Message: Logged In: YES user_id=31435 Reopening until we know more. ---------------------------------------------------------------------- Comment By: Thorsten Henninger (thenninger) Date: 2003-10-02 14:07 Message: Logged In: YES user_id=878819 thank you, that makes sense! i will notice pycurl and have a look in th pycurl source! ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-02 12:25 Message: Logged In: YES user_id=31435 You should report this to the pycurl project. The specific error message you report is new in Python 2.3, doing a check for errnoneous usage of the Python C API. That check didn't exist in Python 2.2. While it's possible there's a previously unreported error in Python 2.3 here, it's much more likely that the problem is in pycurl's C code, and that the error there simply went undetected before Python 2.3, appearing to work by luck. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-02 06:51 Message: Logged In: YES user_id=6656 Why do you think this is a bug in Python and not pycurl? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816476&group_id=5470 From noreply at sourceforge.net Sat Oct 4 16:29:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 16:30:52 2003 Subject: [Python-bugs-list] [ python-Bugs-792101 ] urllib.urlopen for https doesn't always provide readlines Message-ID: Bugs item #792101, was opened at 2003-08-20 13:50 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792101&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gary Feldman (garyfx) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen for https doesn't always provide readlines Initial Comment: The doc for urllib.urlopen says that the object returned supports readlines. However, I have a simple case where it doesn't seem to raise IOError, but readlines isn't provided. The initial problem seems to be in addbase.__init__, which tests fp for readlines, but doesn't do anything if it's not there. Presumably it should either provide a dummy or raise an error (or alternatively, change the documented behavior to match). ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-04 15:29 Message: Logged In: YES user_id=139865 SSLFile was providing a minimal set of file operations. Patch #817854 adds all methods that the urllib documentation expects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792101&group_id=5470 From noreply at sourceforge.net Sat Oct 4 20:08:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 4 20:08:24 2003 Subject: [Python-bugs-list] [ python-Bugs-817920 ] select behavior undefined for empty lists Message-ID: Bugs item #817920, was opened at 2003-10-05 02: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=817920&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vaclav Dvorak (vdvo) Assigned to: Nobody/Anonymous (nobody) Summary: select behavior undefined for empty lists Initial Comment: The manual for select.select() says: "Empty lists are allowed, but acceptance of three empty lists is platform-dependent. (It is known to work on Unix but not on Windows.)" I believe that one of the advantages of high-level languages is that they (are supposed to) shield the programmer from platform specifics where possible. Surely it can't be a problem for the select() wrapper to have defined, platform-independent behaviour for three empty lists? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817920&group_id=5470 From noreply at sourceforge.net Sun Oct 5 02:30:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 02:30:32 2003 Subject: [Python-bugs-list] [ python-Bugs-818006 ] ossaudiodev FileObject does not support closed const Message-ID: Bugs item #818006, was opened at 2003-10-05 02: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=818006&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Cinege (dcinege) Assigned to: Nobody/Anonymous (nobody) Summary: ossaudiodev FileObject does not support closed const Initial Comment: fin = ossaudiodev.open(dspfile, 'r') if fin.closed == True: AttributeError: closed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470 From noreply at sourceforge.net Sun Oct 5 04:49:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 04:49:56 2003 Subject: [Python-bugs-list] [ python-Bugs-818029 ] installer wakes up Windows File Protection Message-ID: Bugs item #818029, was opened at 2003-10-05 08:49 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=818029&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pete (thegoldenear) Assigned to: Nobody/Anonymous (nobody) Summary: installer wakes up Windows File Protection Initial Comment: installing Python 2.3.2 on Windows 2000 SP4 induced the Windows File Protection, presumably bcos an existing system file had been replaced by an older version ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 From noreply at sourceforge.net Sun Oct 5 04:55:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 04:55:53 2003 Subject: [Python-bugs-list] [ python-Bugs-818030 ] use Windows' default programs location. Message-ID: Bugs item #818030, was opened at 2003-10-05 08:55 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=818030&group_id=5470 Category: Windows Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Pete (thegoldenear) Assigned to: Tim Peters (tim_one) Summary: use Windows' default programs location. Initial Comment: The Python 2.3.2 installer chooses its own program-specific installation location of c:\python23. instead it should be using Windows' default location, so that it matches whatever place I have chosen to install programs to. this would save people always having to manually change the location. for example on my systems I use d:\programs and out-of-the-box Windows defaults to c:\Program Files ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818030&group_id=5470 From noreply at sourceforge.net Sun Oct 5 06:50:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 06:50:34 2003 Subject: [Python-bugs-list] [ python-Bugs-818059 ] os.listdir on empty strings. Inconsistent behaviour. Message-ID: Bugs item #818059, was opened at 2003-10-05 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=818059&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hannu Kankaanp?? (hannukoo) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir on empty strings. Inconsistent behaviour. Initial Comment: Behaviour tested in Python 2.3 (final) and 2.3.2 (final). os.listdir('') and os.listdir(u'') have very different behaviour across different OSes: WinXP/WinNT: os.listdir('') -- current dir (e.g. c:\python) os.listdir(u'') -- root dir (e.g. c:\) Win98 os.listdir('') -- root dir os.listdir(u'') -- root dir Redhat Linux 9.0 os.listdir('') -- OSError os.listdir(u'') -- OSError Particularly weird is the WinXP/WinNT behaviour that is different between unicode and normal strings. Suggestion for fix: Make os.listdir for empty strings always raise an exception or always list the current working directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818059&group_id=5470 From noreply at sourceforge.net Sun Oct 5 07:09:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 07:09:28 2003 Subject: [Python-bugs-list] [ python-Bugs-818065 ] mailbox._Subfile readline() bug Message-ID: Bugs item #818065, was opened at 2003-10-05 11: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=818065&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Perez (jbperez808) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox._Subfile readline() bug Initial Comment: mailbox._Subfile's readline() will chop off the first character of the next line when reading Unix-style terminated files. It's surprising no one has mentioned this before. The problem lies in line mailbox._Subfile.readline() itself where self.pos is assigned self.fp.tell()'s value. You will need to subtract 1 from self.pos if a file uses unix-style termination. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818065&group_id=5470 From noreply at sourceforge.net Sun Oct 5 10:41:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 10:41:22 2003 Subject: [Python-bugs-list] [ python-Bugs-817611 ] Google kills socket lookup Message-ID: Bugs item #817611, was opened at 2003-10-04 11:11 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817611&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerd Schulz (spikeee) Assigned to: Nobody/Anonymous (nobody) Summary: Google kills socket lookup Initial Comment: Just test: >>> socket.gethostbyname('www.google.com') '216.239.39.99' >>> socket.gethostbyaddr('216.239.39.99') Traceback (most recent call last): File "", line 1, in ? herror: (11004, 'host not found') Don't know why. Maybe of this strange akadns-stuff?!?! He struggles around for quite a time before he comes to the error, maybe to much or cyclic input. Cheers, Spikeee ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-10-05 16:41 Message: Logged In: YES user_id=580910 This is not a bug/feature of the python socket module, but of DNS itself. DNS uses a seperate tree to find the name associated with an IP adres, there is no entry for the address associated with www.google.com. The same feature can be observed from the command-line: $ nslookup www.google.com ns.xs4all.nl Server: ns.xs4all.nl Address: 194.109.6.66#53 Non-authoritative answer: www.google.com canonical name = www.google.akadns.net. Name: www.google.akadns.net Address: 216.239.59.99 $ nslookup 216.239.59.99 ns.xs4all.nl Server: ns.xs4all.nl Address: 194.109.6.66#53 ** server can't find 99.59.239.216.in-addr.arpa: NXDOMAIN ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817611&group_id=5470 From noreply at sourceforge.net Sun Oct 5 12:44:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 12:44:59 2003 Subject: [Python-bugs-list] [ python-Bugs-814654 ] 'import Tkinter' causes windows missing-DLL popup Message-ID: Bugs item #814654, was opened at 2003-09-29 15:01 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814654&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Cory Dodt (xant) Assigned to: Martin v. L?wis (loewis) Summary: 'import Tkinter' causes windows missing-DLL popup Initial Comment: Python.org's official windows installer makes installing Tkinter optional; there is a component you can uncheck during installation. If this box is unchecked, tk84.dll and friends are not installed but Tkinter.py, _tkinter.pyd and a few others are installed. This makes it difficult to write code that does: .try: . import Tkinter .except ImportError: . # fallback to textmode operation When 'import Tkinter' executes on Windows, Windows attempts to load tk84.dll, and the result is a popup error saying . "The dynamic link library tk84.dll could not be found in the specified path (...my system path...)" I recommend that Tkinter.py and friends not be installed when that box is unchecked, since they can't do anything useful anyway. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-05 12:44 Message: Logged In: YES user_id=593130 I believe that one reason to uncheck the load tk84 box is if one already has it loaded and running. If so, not loading Tkinter.py is exactly the wrong thing to do, and the needed fix is for the Tkinter import to somehow catch the Windows error (no idea how) and convert it to Python ImportError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814654&group_id=5470 From noreply at sourceforge.net Sun Oct 5 12:57:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 12:57:46 2003 Subject: [Python-bugs-list] [ python-Bugs-817920 ] select behavior undefined for empty lists Message-ID: Bugs item #817920, was opened at 2003-10-05 02:08 Message generated for change (Comment added) made by itamar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817920&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Vaclav Dvorak (vdvo) Assigned to: Nobody/Anonymous (nobody) Summary: select behavior undefined for empty lists Initial Comment: The manual for select.select() says: "Empty lists are allowed, but acceptance of three empty lists is platform-dependent. (It is known to work on Unix but not on Windows.)" I believe that one of the advantages of high-level languages is that they (are supposed to) shield the programmer from platform specifics where possible. Surely it can't be a problem for the select() wrapper to have defined, platform-independent behaviour for three empty lists? ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2003-10-05 18:57 Message: Logged In: YES user_id=32065 Both asyncore and Twisted have code to deal with this Windows issue, so most people never encounter it. A fix (doing a sleep in the C code, essentially) would be nice, but I suspect no one will bother unless you attach a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817920&group_id=5470 From noreply at sourceforge.net Sun Oct 5 13:13:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 13:13:15 2003 Subject: [Python-bugs-list] [ python-Bugs-814654 ] 'import Tkinter' causes windows missing-DLL popup Message-ID: Bugs item #814654, was opened at 2003-09-29 12:01 Message generated for change (Comment added) made by xant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814654&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Cory Dodt (xant) Assigned to: Martin v. L?wis (loewis) Summary: 'import Tkinter' causes windows missing-DLL popup Initial Comment: Python.org's official windows installer makes installing Tkinter optional; there is a component you can uncheck during installation. If this box is unchecked, tk84.dll and friends are not installed but Tkinter.py, _tkinter.pyd and a few others are installed. This makes it difficult to write code that does: .try: . import Tkinter .except ImportError: . # fallback to textmode operation When 'import Tkinter' executes on Windows, Windows attempts to load tk84.dll, and the result is a popup error saying . "The dynamic link library tk84.dll could not be found in the specified path (...my system path...)" I recommend that Tkinter.py and friends not be installed when that box is unchecked, since they can't do anything useful anyway. ---------------------------------------------------------------------- >Comment By: Cory Dodt (xant) Date: 2003-10-05 10:13 Message: Logged In: YES user_id=6365 That didn't occur to me. I don't know if it's possible to catch the error message before it becomes a popup window, although it certainly should be, but there's an easier way: .from twisted.runner.procutils import which .if sys.version_info[:2]==(2,2): . tkdll='tk83.dll' .else: . tkdll='tk84.dll' .if which(tkdll): . ... At this point I "try: import Tkinter", but you probably want to negate the condition and raise ImportError here instead. If it's not in the system binary path, it's probably not installed; if it is installed, the user wants to add it to the binary path anyway. (The ImportError itself can suggest this course of action.) Of course, Twisted isn't in stdlib, but which() is a very small utility function: http://cvs.twistedmatrix.com/cvs/twisted/runner/procutils.py?rev=1.2&content-type=text/vnd.viewcvs-markup ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-05 09:44 Message: Logged In: YES user_id=593130 I believe that one reason to uncheck the load tk84 box is if one already has it loaded and running. If so, not loading Tkinter.py is exactly the wrong thing to do, and the needed fix is for the Tkinter import to somehow catch the Windows error (no idea how) and convert it to Python ImportError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814654&group_id=5470 From noreply at sourceforge.net Sun Oct 5 13:37:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 13:37:48 2003 Subject: [Python-bugs-list] [ python-Bugs-818201 ] distutils: clean -b ignored; set_undefined_options doesn't Message-ID: Bugs item #818201, was opened at 2003-10-05 12: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=818201&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nicholas Riley (nriley) Assigned to: Nobody/Anonymous (nobody) Summary: distutils: clean -b ignored; set_undefined_options doesn't Initial Comment: I reported this on the distutils-sig list and didn't receive any response. I'd be happy to provide a patch, but I'm not sure which way to go. Here's something that I think should work: % python setup.py --help clean [...] Options for 'clean' command: --build-base (-b) base build directory (default: 'build.build-base') % python setup.py clean -b ../builds running clean Nothing happens. This works, however: % python setup.py build -b ../builds clean running build running build_py running build_ext running config gcc -E -I/Library/Frameworks/Python.framework/Versions/ 2.3/include/python2.3 -o_configtest.i _configtest.c removing: _configtest.c _configtest.i running clean removing '../builds/temp.darwin-6.8-Power_Macintosh-2.3' (and everything under it) The logic to set build_temp from build_base (-b) is only present in the build command, not in the clean command. The code to set this option runs from clean.set_undefined_options. But it's clean's build_base option which is set at the time, not build's, so it propagates an empty path. The test command class I found posted to the distutils-sig mailing list has a workaround for the above problem, which looks like this: def finalize_options(self): build = self.distribution.get_command_obj('build') build_options = ('build_base', 'build_purelib', 'build_platlib') for option in build_options: setattr(build, option, getattr(self, option)) build.ensure_finalized() for option in build_options: setattr(self, option, getattr(build, option)) and doesn't call self.set_undefined_options at all, though the last three lines could be replaced by it. There are several solutions I can think of: - set_undefined_options should be changed to propagate set options to the source command object before calling src_cmd_obj.ensure_finalized. - another method should be added to the cmd class, which does the above propagation then calls set_undefined_options. - a workaround such as the one above should be placed in the distutils.command.clean.clean class. Does this make sense? Unless there's a huge compatibility issue, I'd favor the first option, but my experience with distutils is limited. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818201&group_id=5470 From noreply at sourceforge.net Sun Oct 5 14:09:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 14:09:25 2003 Subject: [Python-bugs-list] [ python-Bugs-818030 ] use Windows' default programs location. Message-ID: Bugs item #818030, was opened at 2003-10-05 04:55 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818030&group_id=5470 Category: Windows Group: Feature Request >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Pete (thegoldenear) Assigned to: Tim Peters (tim_one) Summary: use Windows' default programs location. Initial Comment: The Python 2.3.2 installer chooses its own program-specific installation location of c:\python23. instead it should be using Windows' default location, so that it matches whatever place I have chosen to install programs to. this would save people always having to manually change the location. for example on my systems I use d:\programs and out-of-the-box Windows defaults to c:\Program Files ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-05 14:09 Message: Logged In: YES user_id=31435 The Python installer used to do this. We won't do it again. By default, we pick a directory on the boot drive with no embedded spaces, and one equal to its DOS 8.3 name. Violating any of those creates needless problems, so we won't violate it by default. You're of course free to chose a different directory, in which case you can solve the problems you create for yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818030&group_id=5470 From noreply at sourceforge.net Sun Oct 5 14:12:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 14:12:31 2003 Subject: [Python-bugs-list] [ python-Bugs-818029 ] installer wakes up Windows File Protection Message-ID: Bugs item #818029, was opened at 2003-10-05 04:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 >Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pete (thegoldenear) >Assigned to: Thomas Heller (theller) Summary: installer wakes up Windows File Protection Initial Comment: installing Python 2.3.2 on Windows 2000 SP4 induced the Windows File Protection, presumably bcos an existing system file had been replaced by an older version ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-05 14:12 Message: Logged In: YES user_id=31435 Changed category to Windows and assigned to Thomas Heller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 From noreply at sourceforge.net Sun Oct 5 14:31:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 14:31:45 2003 Subject: [Python-bugs-list] [ python-Bugs-816627 ] file read() forgets some bytes Message-ID: Bugs item #816627, was opened at 2003-10-02 17:54 Message generated for change (Comment added) made by pfremy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816627&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: file read() forgets some bytes Initial Comment: It seems the python miscalculates the size of a file. This is on windows, with python 2.2.2 from ActiveState E:\work\jayacard\inkit\demo>python ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array, os >>> fname = "current_img.jpg" >>> print len(open(fname).read()) 41 >>> print os.stat(fname).st_size 693 As you can see, there some mismatch here. 693 is indeed the size reported by the windows explorer. >>> a = array.array('B') >>> a.fromfile( open(fname), 693) Traceback (most recent call last): File "", line 1, in ? EOFError: not enough items in file >>> a.fromfile(open(fname), 42) Traceback (most recent call last): File "", line 1, in ? EOFError: not enough items in file >>> a.fromfile(open(fname), 41) >>> a = array.array('B') >>> a.fromfile(open(fname), 41) >>> len(a) 41 I attach the nasty file This is a very serious bug for me. ---------------------------------------------------------------------- >Comment By: Philippe Fremy (pfremy) Date: 2003-10-05 20:31 Message: Logged In: YES user_id=233844 Thanks a lot for the answer. But is there any advantage in opening a file in ascii mode ? Why not open every windows file in binary mode by default, and treat it internall as an ascii file later on, if it turns out to be one ? With python returning always strings, the distinction makes very little sense. This is the kind of thing that will unfortunately make a program more difficult to port. I guess it is too late to change this behaviour. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-02 18:02 Message: Logged In: YES user_id=31435 Windows makes a distinction between binary-mode and text- mode files. open() defaults to text-mode. A .jpg is certainly a binary file, so on Windows you *must* open with it in binary mode. That means changing your open(fname) to open(fname, 'rb') Your problem will go away then. It's unfortunate, but that's the way Windows works -- it's not a Python bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816627&group_id=5470 From noreply at sourceforge.net Sun Oct 5 15:11:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 15:11:51 2003 Subject: [Python-bugs-list] [ python-Bugs-816627 ] file read() forgets some bytes Message-ID: Bugs item #816627, was opened at 2003-10-02 11: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=816627&group_id=5470 Category: Python Library Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Philippe Fremy (pfremy) Assigned to: Nobody/Anonymous (nobody) Summary: file read() forgets some bytes Initial Comment: It seems the python miscalculates the size of a file. This is on windows, with python 2.2.2 from ActiveState E:\work\jayacard\inkit\demo>python ActivePython 2.2.2 Build 224 (ActiveState Corp.) based on Python 2.2.2 (#37, Nov 26 2002, 10:24:37) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import array, os >>> fname = "current_img.jpg" >>> print len(open(fname).read()) 41 >>> print os.stat(fname).st_size 693 As you can see, there some mismatch here. 693 is indeed the size reported by the windows explorer. >>> a = array.array('B') >>> a.fromfile( open(fname), 693) Traceback (most recent call last): File "", line 1, in ? EOFError: not enough items in file >>> a.fromfile(open(fname), 42) Traceback (most recent call last): File "", line 1, in ? EOFError: not enough items in file >>> a.fromfile(open(fname), 41) >>> a = array.array('B') >>> a.fromfile(open(fname), 41) >>> len(a) 41 I attach the nasty file This is a very serious bug for me. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-05 15:11 Message: Logged In: YES user_id=31435 Text files must be opened in text mode in order to (at least) hide platform differences in how line endings are represented. For example, on Linux a line ends with \n, on Windows with \r\n, and on classic Macintoshes with \r. Python has no control over what the native operating system conventions are. But when a text file is opened in text mode, Python hides the platform differences, making all lines *appear* as if they ended with \n on input. On output to a file opened in text mode, Python changes \n to whatever the platform convention is for ending a line. If it didn't do this, text files created with Python would be unusable by non-Python programs on your system, and text files created by non- Python programs on your system would be unusable by Python. The distinction between text mode and binary mode didn't originate with Python, and all you can do is try to live with it. The distinction is simply a reality on most non-Unix systems (Unix treats text and binary mode exactly the same). Note that it's not possible either to guess whether a file is *intended* to be text mode or binary mode by staring at its contents. The distinction is in the mind of the programmer who created the file. So it goes. Portability isn't hard despite all this: always open binary files in binary mode, and always open text files in text mode. That's it. ---------------------------------------------------------------------- Comment By: Philippe Fremy (pfremy) Date: 2003-10-05 14:31 Message: Logged In: YES user_id=233844 Thanks a lot for the answer. But is there any advantage in opening a file in ascii mode ? Why not open every windows file in binary mode by default, and treat it internall as an ascii file later on, if it turns out to be one ? With python returning always strings, the distinction makes very little sense. This is the kind of thing that will unfortunately make a program more difficult to port. I guess it is too late to change this behaviour. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-02 12:02 Message: Logged In: YES user_id=31435 Windows makes a distinction between binary-mode and text- mode files. open() defaults to text-mode. A .jpg is certainly a binary file, so on Windows you *must* open with it in binary mode. That means changing your open(fname) to open(fname, 'rb') Your problem will go away then. It's unfortunate, but that's the way Windows works -- it's not a Python bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816627&group_id=5470 From noreply at sourceforge.net Sun Oct 5 15:46:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 15:46:24 2003 Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out with threads Message-ID: Bugs item #775414, was opened at 2003-07-22 02:29 Message generated for change (Comment added) made by roundeye You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Gregory P. Smith (greg) Summary: bsddb3 hash craps out with threads Initial Comment: Richie Hindle presented something like the attached (hammer.py) on the spambayes-dev mailing list. On Win98SE and Win2K w/ Python 2.3c1 I usually see this death pretty quickly: Traceback (most recent call last): File "hammer.py", line 36, in ? main() File "hammer.py", line 33, in main hammer(db) File "hammer.py", line 15, in hammer x = db[str(int(random.random() * 100000))] File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, in __getitem__ return self.db[key] bsddb._db.DBRunRecoveryError: (-30982, 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal region error detected; run recovery') Richie also reported "illegal operation" crashes on Win98SE. It's not clear whether a bsddb3 hash *can* be used with threads like this. If it can't, there's a doc bug. If it should be able to, there's a more serious problem. Note that it looks like hashopen() always merges DB_THREAD into the flags, so the absence of specifying DB_THREAD probably isn't the problem. ---------------------------------------------------------------------- Comment By: Rick Bradley (roundeye) Date: 2003-10-05 19:46 Message: Logged In: YES user_id=58334 This is also showing up in Syncato (http://www.syncato.org/), and the database isn't recoverable using the Berkeley DB db_recover utility (even using the "catastrophic" flag). Does anyone know of a reliable way to recover? Rick Bradley ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 17:05 Message: Logged In: YES user_id=44345 Forgot to mention that without the DBEnv() object, it gets a segmentation violation on Solaris 8 seg faults pretty quickly (within 10,000 iterations for each thread) or raises bsddb._db.DBRunRecoveryError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 16:41 Message: Logged In: YES user_id=44345 I built from CVS head on a Solaris machine. bsddb.__version__ reports '4.2.1'. When run, the studly_hammer.py script completes the dbenv.open() call, but appears to hang during the hashopen() call. Adding some print statements to hashopen() indicates that it hangs during d.open(). I don't know what to make of this. If others have some suggestions, I'll be happy to try them out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 14:15 Message: Logged In: YES user_id=31435 Greg, I'm in a constant state of debugging (in other apps) thread problems that *appear* unique to Win9x. But in years of this, I have yet to see one that actually is unique to Win9x -- in the end, they always turn out to be legit races in the app I'm debugging, and can always be reproduced on other platforms if the test is made stressful enough and/or run long enough. Win9x appears especially good at provoking thread problems just because its scheduling is erratic, often acting like a Linux system under extreme load that way. IOW, unless there's a bug in Sleepycat's implementation of locking on Win9x, I bet dollars to doughnuts this program will eventually deadlock everywhere. In Python's lifetime, across dozens of miserable thread problems, we haven't pinned the blame once on Win9x. That wasn't for lack of trying . ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-29 07:42 Message: Logged In: YES user_id=29957 I'd be much happier with a documentation fix for 2.3.2. Note that when I said "fails to complete" on Solaris, I meant that it crashes out, not that it deadlocks. I can post the tracebacks here if you'd like. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-29 07:02 Message: Logged In: YES user_id=413 anthony - if we don't put this patch into python 2.3.2, the python 2.3.x bsddb module documentation should be updated to say that multithreaded access is not supported and will cause problems, possibly even python interpreter crashes. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-29 06:57 Message: Logged In: YES user_id=413 Deadlocks only occurring under DOS-based "windows" (win95/98/me) aren't something the python module can prevent. I suggest submitting the sample code and info from studly_hammer.py to sleepycat. They're usually very responsive to questions of that nature. btw, i'll give things a go on solaris later this week. if the test suite never completes i again suspect it is a berkeleydb library issue on that platform rather than python module. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 01:38 Message: Logged In: YES user_id=31435 Running the original hammer.py under current CVS Python freezes in the same way (as in my immediately preceding note) now too; again Win98SE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 01:28 Message: Logged In: YES user_id=31435 About studly_hammer.py: [Skip Montanaro] > ... > Attached is a modified version of the hammer.py script which seems to > not fail for me on either Windows run from IDLE (Python 2.3, BDB > 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1). The original script > failed for me on Windows but not Mac OS X. Can some other people for > whom the original script fails please try it? (I also attached it to > bug #775414.) On Win98SE with current Python 2.3.1, it doesn't fail, but it never seemed to finish for me either. Staring at WinTop showed that the Python process stopped accumulating cycles. Can't be killed with Ctrl+C (no visible effect). Can be killed with Ctrl+Break. Dumping print "%s %s" % (thread.get_ident(), i) at the top of the hammer loop showed that the threads get through several hundred iterations, then all printing stops. Attaching to a debug-build Python from the debugger when a freeze occurs isn't terribly illuminating. One thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __ham_get_meta + 120 bytes _BSDDB_D! __ham_c_dup + 4201 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, __db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 562 + 35 bytes The main thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __db_lget + 365 bytes _BSDDB_D! __ham_lock_bucket + 105 bytes _BSDDB_D! __ham_get_cpage + 195 bytes _BSDDB_D! __ham_item_next + 25 bytes _BSDDB_D! __ham_call_hash + 2479 bytes _BSDDB_D! __ham_c_dup + 4307 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, __db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 562 + 35 bytes DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 2330 + 23 bytes PyObject_SetItem(_object * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 123 + 18 bytes eval_frame(_frame * 0x00984948) line 1448 + 17 bytes ... The other threads are somewhere in the OS kernel and don't have useful tracebacks. This varies from run to run, but all threads with a useful stack are always stuck at the same place in __db_win32_mutex_lock. All in all, looks like it's simply deadlocked. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-28 05:11 Message: Logged In: YES user_id=29957 Could you check that it (and the test_bsddb3) works on Solaris? There's a couple of solaris boxes on the SF compile farm (cf.sf.net). I was unable to get test_bsddb3 to complete at all on Solaris 2.6, 7 or 8, when using DB 4.1.25. As far as 2.3.2, I really really don't think it's appropriate to throw it in at this late point. Particularly given the 2.3.1 screwups, I don't want to risk it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-27 23:08 Message: Logged In: YES user_id=413 I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database. hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25. (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters). After others have tested this on other platforms with success I believe we can close this bug. This patch would probably be good for python 2.3.2. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-27 18:10 Message: Logged In: YES user_id=44345 If hammer.py fails for you, please try this slightly modified version (studly_hammer.py). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 22:28 Message: Logged In: YES user_id=413 I don't see any problem in _bsddb.c:_DB_put(), what memory are you talking about? All of the DBT key and data parameters are allocated on the local stack on the various DB methods that call _DB_put. What do you see that could be clobbered? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 19:52 Message: Logged In: YES user_id=44345 The sleepycat mails (there are two of them - Keith's is second) are in the attached sleepy.txt file. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-09-12 19:25 Message: Logged In: YES user_id=85414 Sorry to muddy the waters, but I'm 99% sure that this is not a threading issue. Today I had the same DBRunRecoveryError for my Spambayes POP3 proxy classifier database, which only ever gets accessed from the main program thread. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 19:22 Message: Logged In: YES user_id=31392 I don't want to sound like a broken record, but I will: Can anyone comment on the lack of thread-safety in _DB_put()? It appears that there is nothing to prevent the memory used by one call from being stomped on by another call in a different thread. This problem would exist even in an application using the modern interface and specifying DB_THREAD. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 19:10 Message: Logged In: YES user_id=413 Looking at bsddb/__init__.py (where the old bsddb compatibility interface is implemented) I don't see why the hammer.py attached below should cause a problem. The database is opened with DB_THREAD using a private environment (no DBEnv passed to DB()). I definately see potential threading problems with the _DBWithCursor class defined there if any of the methods using a cursor are used (the cursor could be shared across threads; that's a no-no). But in the context of hammer.py that doesn't happen so I wouldn't have expected a problem. Unless perhaps creating the DB withou a DBEnv implies that the DB_THREAD flag won't work. The DB_RECOVER flag is only useful for opening existing DBEnv's; we have none. I've got to pop offline for a bit now but i'll try a hammer.py modified to use direct DB calls (for easier playing around with and bug reporting to sleepycat if turns out to be a bug on their end) later tonight. PS keiths response is in the sleepycat.txt attachment if you open the URL to this bug report on sourceforge. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 19:07 Message: Logged In: YES user_id=31435 Jeremy, Keith's response is in the sleepy.txt file attached to the bug report. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 19:03 Message: Logged In: YES user_id=31392 I don't see Keith's response anywhere in this thread. Can you add it for the record? The only call to db->put() that I see is in _DB_put(). It does not look thread-safe to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 19:00 Message: Logged In: YES user_id=44345 The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. But the low-level open() call isn't made with a DBEnv argument is it? Nor is the DB_RECOVER flag set. Would the compatibility interface be able to do both things? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 18:57 Message: Logged In: YES user_id=44345 In theory, yes, we could special case the bsddb stuff. However, the code currently is run indirectly via the anydbm module. It will take a little effort on our part to do something special for bsddb. It would be nice if other apps using the naive interface were able to use multiple threads. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 18:45 Message: Logged In: YES user_id=413 ah, Keith's response from sleepycat assumed that we were using the DB 1.85 compatibility interface. We do not. The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 18:37 Message: Logged In: YES user_id=31392 Are the DB_mapping methods only used the old interface? My question is about those methods, which I assumed were used by the old and new interfaces. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 18:30 Message: Logged In: YES user_id=413 The old bsddb interface compatibility code could be modified to use a single DBEnv per process opened with the DB_SYSTEM_MEM flag. Do we want to do this? Shouldn't we encourage the use of the real pybsddb DB/DBEnv object interface for threads instead? AFAIK the old bsddb module + libs were not thread safe. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 18:23 Message: Logged In: YES user_id=44345 >From what I got back from Sleepycat on this, I'm pretty sure the old bsddb interface is not going to be thread safe. Attached are two messages from Sleepycat. Is there some way for the old interface to create a default environment shared by all the bsddb.*open() calls and then set the DB_RECOVER flag in the low-level open() call? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 17:14 Message: Logged In: YES user_id=31392 How does the bsddb wrapper achieve thread safety? I know very little about the wrapper or the underlying bsddb libraries. I found the following comment in the C API docs: http://www.sleepycat.com/docs/ref/program/mt.html#2 > When using the non-cursor Berkeley DB calls to retrieve > key/data items (for example, DB->get), the memory to which the > pointer stored into the Dbt refers is valid only until the next call > using the DB handle returned by DB->open. This includes any > use of the returned DB handle, including by another thread > within the process. This suggests that a call to a self->db->get() must process its results (copy them into Python-owned memory) before any other operation on the same db object can proceed. Is that right? The bsddb wrapper releases the GIL before calling the low-level DB API functions and the acquires it after the call returns. Is there some other lock that prevents multiple simultaneous calls from stomping on each other? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 16:46 Message: Logged In: YES user_id=31392 I'm running this test with CVS Python (built on 9/11/03) on RH Linux 9 with bsddb 4.1.25. I see the same error although it takes a relatively long time to provoke -- a minute or two. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 16:08 Message: Logged In: YES user_id=31435 Greg, any luck? We're starting to see the same error ("fatal region error detected") in some ZODB tests using bsddb3, and that's an infinitely more complicated setup than this little program. Jeremy Hylton also sees "fatal region" errors on Linux, in the ZODB context. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-08-13 23:26 Message: Logged In: YES user_id=413 i'll try and reproduce this. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-07-22 08:50 Message: Logged In: YES user_id=85414 Minor correction: I'm on Plain Old Win98, not SE. For what it's worth, the script seems more often than not to provoke an application error when there's background load, and a DBRunRecoveryError when there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 From noreply at sourceforge.net Sun Oct 5 16:16:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 16:16:31 2003 Subject: [Python-bugs-list] [ python-Bugs-818006 ] ossaudiodev FileObject does not support closed const Message-ID: Bugs item #818006, was opened at 2003-10-05 02:30 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Cinege (dcinege) Assigned to: Nobody/Anonymous (nobody) Summary: ossaudiodev FileObject does not support closed const Initial Comment: fin = ossaudiodev.open(dspfile, 'r') if fin.closed == True: AttributeError: closed ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-05 16:16 Message: Logged In: YES user_id=593130 >From Lib Ref 14.11 ossaudiodev "open( [device, ]mode) Open an audio device and return an OSS audio device object. " Checking http://python.org/doc/current/lib/ossaudio-device- objects.html 14.11.1 Audio Device Objects I can find no mention of closed attribute or indeed of any attributes other than methods. Why were you expecting such? If report is a mistake, please close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470 From noreply at sourceforge.net Sun Oct 5 16:32:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 16:32:37 2003 Subject: [Python-bugs-list] [ python-Bugs-818006 ] ossaudiodev FileObject does not support closed const Message-ID: Bugs item #818006, was opened at 2003-10-05 02:30 Message generated for change (Comment added) made by dcinege You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dave Cinege (dcinege) Assigned to: Nobody/Anonymous (nobody) Summary: ossaudiodev FileObject does not support closed const Initial Comment: fin = ossaudiodev.open(dspfile, 'r') if fin.closed == True: AttributeError: closed ---------------------------------------------------------------------- >Comment By: Dave Cinege (dcinege) Date: 2003-10-05 16:32 Message: Logged In: YES user_id=314434 Please see: http://python.org/doc/current/lib/bltin-file-objects.html """ File objects also offer a number of other interesting attributes. These are not required for file-like objects, but should be implemented if they make sense for the particular object. "" "Should be" when they "make sense" is my rational for reporting this as a bug. I found this by trying to convert existing code from a normal open of /dev/dsp to ossaudiodev.open(), that IMO "should" have worked. : P Other attributes that "should be" implemented (mode and name) because they "make sense" may also be missing...I haven't checked. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-05 16:16 Message: Logged In: YES user_id=593130 >From Lib Ref 14.11 ossaudiodev "open( [device, ]mode) Open an audio device and return an OSS audio device object. " Checking http://python.org/doc/current/lib/ossaudio-device- objects.html 14.11.1 Audio Device Objects I can find no mention of closed attribute or indeed of any attributes other than methods. Why were you expecting such? If report is a mistake, please close. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818006&group_id=5470 From noreply at sourceforge.net Sun Oct 5 17:21:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 17:21:39 2003 Subject: [Python-bugs-list] [ python-Bugs-818029 ] installer wakes up Windows File Protection Message-ID: Bugs item #818029, was opened at 2003-10-05 03:49 Message generated for change (Comment added) made by logistix You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pete (thegoldenear) Assigned to: Thomas Heller (theller) Summary: installer wakes up Windows File Protection Initial Comment: installing Python 2.3.2 on Windows 2000 SP4 induced the Windows File Protection, presumably bcos an existing system file had been replaced by an older version ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-10-05 16:21 Message: Logged In: YES user_id=699438 I couldn't reproduce this on a stock install of W2K SP 4. If you're in a position to do so (you'll need the physical CD media), could you rebuild your DLL cache? From the command-line "sfc /purgecache && sfc /scannow" should do this. After that, try to install python2.3.2 and see if sfc kicks in again. If you can't do that, you might want to see if the file python23.dll somehow manually ended up in the %windir% \system32\dllcache directory. As far as I know, thats the only file that should be getting shoved into an area the sfc cares about. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-05 13:12 Message: Logged In: YES user_id=31435 Changed category to Windows and assigned to Thomas Heller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 From noreply at sourceforge.net Sun Oct 5 17:44:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 17:44:06 2003 Subject: [Python-bugs-list] [ python-Bugs-818315 ] Shared object modules in Windows have no __file__. Message-ID: Bugs item #818315, was opened at 2003-10-05 17: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=818315&group_id=5470 Category: None Group: None Status: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818315&group_id=5470 From noreply at sourceforge.net Sun Oct 5 19:41:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 19:41:19 2003 Subject: [Python-bugs-list] [ python-Bugs-812202 ] randint is always even Message-ID: Bugs item #812202, was opened at 2003-09-24 23:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ronald L. Rivest (ronrivest) Assigned to: Raymond Hettinger (rhettinger) Summary: randint is always even Initial Comment: The result of random.randint(2**64,2**65-1) is always even! (I was trying to find some large prime numbers, and was puzzled by the fact that none were turning up. Finally, I discovered that randint wasn't really returning "random" integers as desired, but only even ones.) I'm not sure what the cause of the problem is, but randint should work properly, even when the given endpoints are large... Thanks... Ron Rivest ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-05 18:41 Message: Logged In: YES user_id=80475 Fixed. See: Lib/random.py 1.56 and Modules/_randommodule.c 1.7 Thanks for the bug report. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-02 21:45 Message: Logged In: YES user_id=80475 Here is a patch for Py2.4 that: * implements getrandbits(k) in C * modifies randrange() to use getrandbits() when available * modified randrange() to warn for large ranges whenever getrandbits() is not available * creates a BaseRandom class for generator subclassing A separate patch for Py2.3.3 will be loaded that extends randrange() for only the MersenneTwister and makes no API changes or assumptions about other generators. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-28 02:42 Message: Logged In: YES user_id=80475 A cleaner, faster patch is attached along with tests. Before it goes in, the second assert can be commented out. Unless Tim comes-up with a better idea about obtaining the information content of a call to random(), I think the 53-bit assumption is fine (a bar for core generators to live up to). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-26 23:40 Message: Logged In: YES user_id=80475 Attached is a first draft of a patch. It works but I don't like the globals for 53 bits per random float because the WichmannHill generator supplies fewer bits than that. I don't see a general way to find out how many bits per random call are offered by an underlying generator. A more conservative, but slower approach is to assume on 32 bits and, if there are more, just throw them away. Ideas are welcome. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-25 19:07 Message: Logged In: YES user_id=31435 Ya, something like that indeed. You might enjoy writing the core in C . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-25 12:10 Message: Logged In: YES user_id=80475 If the range is too large, instead of raising an exception, how about calling a _randbigint routine that builds up the random selection using repeated calls to the underlying generator. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-25 10:23 Message: Logged In: YES user_id=31435 No disagreement here. I'd rather fix the code than the docs, and a fix can take two forms: raise an exception if the full range of ints can't be delivered, or deliver the full range of ints. If anyone wants to take this on, I think the latter ("do a right thing") may be much more practical than it used to be, given the new-in-2.3 Twister impelementation -- we can generate long pseudo-random bitstrings quickly now (at least at the C level), but couldn't before 2.3. ---------------------------------------------------------------------- Comment By: Ronald L. Rivest (ronrivest) Date: 2003-09-25 09:56 Message: Logged In: YES user_id=863876 If the code is not going to be fixed, then the documentation should be updated. I am well aware of other approaches to generating large random numbers, but was misled by the documentation Python provides. The documentation should make it clear when the code violates its "contract" (i.e. doesn't generate all integers in the range). I prefer the code being fixed best, but also feel that the code should raise an exception if it can't honor the contract implied in its documentation. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-25 00:16 Message: Logged In: YES user_id=31435 The cause is that randint takes a pseudo-random float (C double in [0, 1),), multiplies it by (hi-lo+1), then truncates and adds that to lo. Since a double on your box almost certainly has only 53 bits of precision, and your multiplier effectively moves the radix point 64 bits "to the right", I expect the last 11 bits you see will always be 0. Under Python 2.3, which uses the Mersenne Twister to generate random doubles, this does appear to be the case: >>> from random import randint >>> def f(): ... return randint(2**64, 2**65-1) ... >>> hex(f()) '0x11EDD95B72CEF4000L' >>> hex(f()) '0x1DD69BF4B39C65000L' >>> hex(f()) '0x13328DC9C1C733800L' >>> hex(f()) '0x1E65B47170C057800L' >>> Under earlier versions of Python, it may be even worse than that. It takes a fundamentally different kind of algorithm to generate arbitrarily long random ints. Here's a link to one such for Python: http://www.faqts.com/knowledge_base/view.phtml/aid/4406 I doubt the implementation of randint() will change, since most people want fast-as-possible generation of mountains of small integers, and there's a tradeoff between catering to that and catering to extreme inputs. The randint docs should change, though (I think randint() used to raise an exception when fed arguments as large as the ones you're using; I suspect, but don't know, that we lost the helpful exception as an unintended consequence of the long-term effort to eradicate the user-visible distinction between Python ints (machine C longs) and Python longs (unbounded integers)). BTW, given what you're doing, you may want to install one of the Python wrappers for GNU GMP. Python's unbounded-int arithmetic implementation is extremely portable and reliable, but buys those in part by not caring much about speed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812202&group_id=5470 From noreply at sourceforge.net Sun Oct 5 21:17:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 21:17:33 2003 Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out with threads Message-ID: Bugs item #775414, was opened at 2003-07-21 19:29 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Gregory P. Smith (greg) Summary: bsddb3 hash craps out with threads Initial Comment: Richie Hindle presented something like the attached (hammer.py) on the spambayes-dev mailing list. On Win98SE and Win2K w/ Python 2.3c1 I usually see this death pretty quickly: Traceback (most recent call last): File "hammer.py", line 36, in ? main() File "hammer.py", line 33, in main hammer(db) File "hammer.py", line 15, in hammer x = db[str(int(random.random() * 100000))] File "C:\CODE\PYTHON\lib\bsddb\__init__.py", line 86, in __getitem__ return self.db[key] bsddb._db.DBRunRecoveryError: (-30982, 'DB_RUNRECOVERY: Fatal error, run database recovery -- fatal region error detected; run recovery') Richie also reported "illegal operation" crashes on Win98SE. It's not clear whether a bsddb3 hash *can* be used with threads like this. If it can't, there's a doc bug. If it should be able to, there's a more serious problem. Note that it looks like hashopen() always merges DB_THREAD into the flags, so the absence of specifying DB_THREAD probably isn't the problem. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-10-05 18:17 Message: Logged In: YES user_id=413 if you believe your application is properly using BerkeleyDB and you are having DB_RUNRECOVERY issues I suggest contacting sleepycat. ---------------------------------------------------------------------- Comment By: Rick Bradley (roundeye) Date: 2003-10-05 12:46 Message: Logged In: YES user_id=58334 This is also showing up in Syncato (http://www.syncato.org/), and the database isn't recoverable using the Berkeley DB db_recover utility (even using the "catastrophic" flag). Does anyone know of a reliable way to recover? Rick Bradley ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 10:05 Message: Logged In: YES user_id=44345 Forgot to mention that without the DBEnv() object, it gets a segmentation violation on Solaris 8 seg faults pretty quickly (within 10,000 iterations for each thread) or raises bsddb._db.DBRunRecoveryError. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-29 09:41 Message: Logged In: YES user_id=44345 I built from CVS head on a Solaris machine. bsddb.__version__ reports '4.2.1'. When run, the studly_hammer.py script completes the dbenv.open() call, but appears to hang during the hashopen() call. Adding some print statements to hashopen() indicates that it hangs during d.open(). I don't know what to make of this. If others have some suggestions, I'll be happy to try them out. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-29 07:15 Message: Logged In: YES user_id=31435 Greg, I'm in a constant state of debugging (in other apps) thread problems that *appear* unique to Win9x. But in years of this, I have yet to see one that actually is unique to Win9x -- in the end, they always turn out to be legit races in the app I'm debugging, and can always be reproduced on other platforms if the test is made stressful enough and/or run long enough. Win9x appears especially good at provoking thread problems just because its scheduling is erratic, often acting like a Linux system under extreme load that way. IOW, unless there's a bug in Sleepycat's implementation of locking on Win9x, I bet dollars to doughnuts this program will eventually deadlock everywhere. In Python's lifetime, across dozens of miserable thread problems, we haven't pinned the blame once on Win9x. That wasn't for lack of trying . ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-29 00:42 Message: Logged In: YES user_id=29957 I'd be much happier with a documentation fix for 2.3.2. Note that when I said "fails to complete" on Solaris, I meant that it crashes out, not that it deadlocks. I can post the tracebacks here if you'd like. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-29 00:02 Message: Logged In: YES user_id=413 anthony - if we don't put this patch into python 2.3.2, the python 2.3.x bsddb module documentation should be updated to say that multithreaded access is not supported and will cause problems, possibly even python interpreter crashes. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-28 23:57 Message: Logged In: YES user_id=413 Deadlocks only occurring under DOS-based "windows" (win95/98/me) aren't something the python module can prevent. I suggest submitting the sample code and info from studly_hammer.py to sleepycat. They're usually very responsive to questions of that nature. btw, i'll give things a go on solaris later this week. if the test suite never completes i again suspect it is a berkeleydb library issue on that platform rather than python module. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-28 18:38 Message: Logged In: YES user_id=31435 Running the original hammer.py under current CVS Python freezes in the same way (as in my immediately preceding note) now too; again Win98SE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-28 18:28 Message: Logged In: YES user_id=31435 About studly_hammer.py: [Skip Montanaro] > ... > Attached is a modified version of the hammer.py script which seems to > not fail for me on either Windows run from IDLE (Python 2.3, BDB > 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1). The original script > failed for me on Windows but not Mac OS X. Can some other people for > whom the original script fails please try it? (I also attached it to > bug #775414.) On Win98SE with current Python 2.3.1, it doesn't fail, but it never seemed to finish for me either. Staring at WinTop showed that the Python process stopped accumulating cycles. Can't be killed with Ctrl+C (no visible effect). Can be killed with Ctrl+Break. Dumping print "%s %s" % (thread.get_ident(), i) at the top of the hammer loop showed that the threads get through several hundred iterations, then all printing stops. Attaching to a debug-build Python from the debugger when a freeze occurs isn't terribly illuminating. One thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __ham_get_meta + 120 bytes _BSDDB_D! __ham_c_dup + 4201 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, __db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 562 + 35 bytes The main thread's stack shows _BSDDB_D! __db_win32_mutex_lock + 134 bytes _BSDDB_D! __lock_get + 2264 bytes _BSDDB_D! __lock_get + 197 bytes _BSDDB_D! __db_lget + 365 bytes _BSDDB_D! __ham_lock_bucket + 105 bytes _BSDDB_D! __ham_get_cpage + 195 bytes _BSDDB_D! __ham_item_next + 25 bytes _BSDDB_D! __ham_call_hash + 2479 bytes _BSDDB_D! __ham_c_dup + 4307 bytes _BSDDB_D! __db_c_put + 2544 bytes _BSDDB_D! __db_put + 507 bytes _DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, __db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 562 + 35 bytes DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 2330 + 23 bytes PyObject_SetItem(_object * 0x008fe2e8, _object * 0x00b83178, _object * 0x00b83370) line 123 + 18 bytes eval_frame(_frame * 0x00984948) line 1448 + 17 bytes ... The other threads are somewhere in the OS kernel and don't have useful tracebacks. This varies from run to run, but all threads with a useful stack are always stuck at the same place in __db_win32_mutex_lock. All in all, looks like it's simply deadlocked. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-27 22:11 Message: Logged In: YES user_id=29957 Could you check that it (and the test_bsddb3) works on Solaris? There's a couple of solaris boxes on the SF compile farm (cf.sf.net). I was unable to get test_bsddb3 to complete at all on Solaris 2.6, 7 or 8, when using DB 4.1.25. As far as 2.3.2, I really really don't think it's appropriate to throw it in at this late point. Particularly given the 2.3.1 screwups, I don't want to risk it. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-27 16:08 Message: Logged In: YES user_id=413 I just committed a change to bsddb/__init__.py (file rev 1.10) that adds the creation of a thread-safe DBEnv object for each hashopen, btopen or rnopen database. hammer.py has been running for 5 minutes on my linux/alpha system using BerkeleyDB 4.1.25. (admittedly my test is running on python 2.2.2, but as this isn't a python core related change i doubt that matters). After others have tested this on other platforms with success I believe we can close this bug. This patch would probably be good for python 2.3.2. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-27 11:10 Message: Logged In: YES user_id=44345 If hammer.py fails for you, please try this slightly modified version (studly_hammer.py). ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 15:28 Message: Logged In: YES user_id=413 I don't see any problem in _bsddb.c:_DB_put(), what memory are you talking about? All of the DBT key and data parameters are allocated on the local stack on the various DB methods that call _DB_put. What do you see that could be clobbered? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 12:52 Message: Logged In: YES user_id=44345 The sleepycat mails (there are two of them - Keith's is second) are in the attached sleepy.txt file. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-09-12 12:25 Message: Logged In: YES user_id=85414 Sorry to muddy the waters, but I'm 99% sure that this is not a threading issue. Today I had the same DBRunRecoveryError for my Spambayes POP3 proxy classifier database, which only ever gets accessed from the main program thread. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 12:22 Message: Logged In: YES user_id=31392 I don't want to sound like a broken record, but I will: Can anyone comment on the lack of thread-safety in _DB_put()? It appears that there is nothing to prevent the memory used by one call from being stomped on by another call in a different thread. This problem would exist even in an application using the modern interface and specifying DB_THREAD. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 12:10 Message: Logged In: YES user_id=413 Looking at bsddb/__init__.py (where the old bsddb compatibility interface is implemented) I don't see why the hammer.py attached below should cause a problem. The database is opened with DB_THREAD using a private environment (no DBEnv passed to DB()). I definately see potential threading problems with the _DBWithCursor class defined there if any of the methods using a cursor are used (the cursor could be shared across threads; that's a no-no). But in the context of hammer.py that doesn't happen so I wouldn't have expected a problem. Unless perhaps creating the DB withou a DBEnv implies that the DB_THREAD flag won't work. The DB_RECOVER flag is only useful for opening existing DBEnv's; we have none. I've got to pop offline for a bit now but i'll try a hammer.py modified to use direct DB calls (for easier playing around with and bug reporting to sleepycat if turns out to be a bug on their end) later tonight. PS keiths response is in the sleepycat.txt attachment if you open the URL to this bug report on sourceforge. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 12:07 Message: Logged In: YES user_id=31435 Jeremy, Keith's response is in the sleepy.txt file attached to the bug report. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 12:03 Message: Logged In: YES user_id=31392 I don't see Keith's response anywhere in this thread. Can you add it for the record? The only call to db->put() that I see is in _DB_put(). It does not look thread-safe to me. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 12:00 Message: Logged In: YES user_id=44345 The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. But the low-level open() call isn't made with a DBEnv argument is it? Nor is the DB_RECOVER flag set. Would the compatibility interface be able to do both things? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 11:57 Message: Logged In: YES user_id=44345 In theory, yes, we could special case the bsddb stuff. However, the code currently is run indirectly via the anydbm module. It will take a little effort on our part to do something special for bsddb. It would be nice if other apps using the naive interface were able to use multiple threads. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 11:45 Message: Logged In: YES user_id=413 ah, Keith's response from sleepycat assumed that we were using the DB 1.85 compatibility interface. We do not. The bsddb module emulates the old bsddb module's 1.85-ish interface using modern DB/DBEnv objects underneath. So his comments about that not being threadsafe don't apply here. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 11:37 Message: Logged In: YES user_id=31392 Are the DB_mapping methods only used the old interface? My question is about those methods, which I assumed were used by the old and new interfaces. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-09-12 11:30 Message: Logged In: YES user_id=413 The old bsddb interface compatibility code could be modified to use a single DBEnv per process opened with the DB_SYSTEM_MEM flag. Do we want to do this? Shouldn't we encourage the use of the real pybsddb DB/DBEnv object interface for threads instead? AFAIK the old bsddb module + libs were not thread safe. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-09-12 11:23 Message: Logged In: YES user_id=44345 >From what I got back from Sleepycat on this, I'm pretty sure the old bsddb interface is not going to be thread safe. Attached are two messages from Sleepycat. Is there some way for the old interface to create a default environment shared by all the bsddb.*open() calls and then set the DB_RECOVER flag in the low-level open() call? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 10:14 Message: Logged In: YES user_id=31392 How does the bsddb wrapper achieve thread safety? I know very little about the wrapper or the underlying bsddb libraries. I found the following comment in the C API docs: http://www.sleepycat.com/docs/ref/program/mt.html#2 > When using the non-cursor Berkeley DB calls to retrieve > key/data items (for example, DB->get), the memory to which the > pointer stored into the Dbt refers is valid only until the next call > using the DB handle returned by DB->open. This includes any > use of the returned DB handle, including by another thread > within the process. This suggests that a call to a self->db->get() must process its results (copy them into Python-owned memory) before any other operation on the same db object can proceed. Is that right? The bsddb wrapper releases the GIL before calling the low-level DB API functions and the acquires it after the call returns. Is there some other lock that prevents multiple simultaneous calls from stomping on each other? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-09-12 09:46 Message: Logged In: YES user_id=31392 I'm running this test with CVS Python (built on 9/11/03) on RH Linux 9 with bsddb 4.1.25. I see the same error although it takes a relatively long time to provoke -- a minute or two. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-09-12 09:08 Message: Logged In: YES user_id=31435 Greg, any luck? We're starting to see the same error ("fatal region error detected") in some ZODB tests using bsddb3, and that's an infinitely more complicated setup than this little program. Jeremy Hylton also sees "fatal region" errors on Linux, in the ZODB context. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-08-13 16:26 Message: Logged In: YES user_id=413 i'll try and reproduce this. ---------------------------------------------------------------------- Comment By: Richie Hindle (richiehindle) Date: 2003-07-22 01:50 Message: Logged In: YES user_id=85414 Minor correction: I'm on Plain Old Win98, not SE. For what it's worth, the script seems more often than not to provoke an application error when there's background load, and a DBRunRecoveryError when there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 From noreply at sourceforge.net Sun Oct 5 23:48:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 23:48:45 2003 Subject: [Python-bugs-list] [ python-Bugs-815646 ] thread unsafe file objects cause crash Message-ID: Bugs item #815646, was opened at 2003-10-01 06:22 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815646&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jan Olderdissen (janixia) Assigned to: Nobody/Anonymous (nobody) Summary: thread unsafe file objects cause crash Initial Comment: Note: This may be a dupe or a generalization of 595601. Running below code snippet on 2.3.1 release and debug build on Windows 2000/XP a few times will inevitably lead to a crash. 2.2.2 also exhibits this behavior. The crashing code: ------------ import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f=open("tmp1", "w") f.seek (0, 0) thread.start_new_thread(worker, ()) thread.start_new_thread(worker, ()) while 1: pass ------------- The issue appears to be this (and similar) code sections from fileobject.c: Py_BEGIN_ALLOW_THREADS errno = 0; ret = _portable_fseek(f->f_fp, offset, whence); Py_END_ALLOW_THREADS Note that due to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS, f->f_fp can be set to NULL by file_close prior to entering _portable_fseek. Similar crashes can be observed with read, write and close itself when they are mixed with a concurrent close. Obviously, the offending python code is buggy and a lock should be used to prevent concurrent access to f. However, it seems unreasonable for Python to crash because of it. A mutex preventing concurrent access to the file object seems like a reasonable way to fix this. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-10-06 03:48 Message: Logged In: YES user_id=31392 Patch 595601 is an attempt to address this problem, but it's incomplete. The file object API allows an extension to extract to FILE * and squirrel it away. That's clearly unsafe, because it can't participate in a locking scheme without re-writing extensions. Shane Hathaway proposed another solution here: http://mail.python.org/pipermail/python-dev/2003-June/036543.html The problem in this case is that we cause the call to close() to raise an exception. I'd prefer to see the exception raised elsewhere, because close() seldom fails and is often closed from routines that are cleaning up at the end. On the other hand, this solution would be easier to implementation, so I'm at least +0 on it. Let's do one or the other. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-04 08:01 Message: Logged In: YES user_id=21627 janixia, don't worry about the formatting - this is partially SF's fault, too. Would you be interested in developing and testing a patch? I think it would be sufficient to move the f->f_fp access out of the GIL releasage. ---------------------------------------------------------------------- Comment By: Jan Olderdissen (janixia) Date: 2003-10-01 07:08 Message: Logged In: YES user_id=877914 My apologies for the mangled source. I suppose there isn't a way for me to remedy the situation. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 07:03 Message: Logged In: YES user_id=29957 Attaching the failing code as an attachment, because SF mangles source code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815646&group_id=5470 From noreply at sourceforge.net Sun Oct 5 23:55:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 5 23:56:02 2003 Subject: [Python-bugs-list] [ python-Bugs-817920 ] select behavior undefined for empty lists Message-ID: Bugs item #817920, was opened at 2003-10-05 00:08 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817920&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Vaclav Dvorak (vdvo) Assigned to: Nobody/Anonymous (nobody) Summary: select behavior undefined for empty lists Initial Comment: The manual for select.select() says: "Empty lists are allowed, but acceptance of three empty lists is platform-dependent. (It is known to work on Unix but not on Windows.)" I believe that one of the advantages of high-level languages is that they (are supposed to) shield the programmer from platform specifics where possible. Surely it can't be a problem for the select() wrapper to have defined, platform-independent behaviour for three empty lists? ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-10-06 03:55 Message: Logged In: YES user_id=31392 Like he said, please provide a patch. ---------------------------------------------------------------------- Comment By: Itamar Shtull-Trauring (itamar) Date: 2003-10-05 16:57 Message: Logged In: YES user_id=32065 Both asyncore and Twisted have code to deal with this Windows issue, so most people never encounter it. A fix (doing a sleep in the C code, essentially) would be nice, but I suspect no one will bother unless you attach a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817920&group_id=5470 From noreply at sourceforge.net Mon Oct 6 01:08:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 6 01:09:07 2003 Subject: [Python-bugs-list] [ python-Bugs-817156 ] invalid \U escape gives 0=length unistr Message-ID: Bugs item #817156, was opened at 2003-10-03 13:30 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817156&group_id=5470 Category: Unicode Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: M.-A. Lemburg (lemburg) Summary: invalid \U escape gives 0=length unistr Initial Comment: >>> u'\Ufffffffe' # CORRECT UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character >>> u'\Uffffffff' # WRONG u'' >>> len(_) 0 Observed on 2.2.2 (redhat wide-unicode build, sys.maxunicode=1114111), 2.3.1 (custom build, sys.maxunicode == 65535) I think the problem is due to this logic in unicodeobject.c:PyUnicode_DecodeUnicodeEscape() if (chr == 0xffffffff) /* _decoding_error will have already written into the target buffer. */ break; perhaps it should be (chr == 0xffffffff && PyErr_Occurred()) I tried this change locally, and it fixes the problem: >>> u'\Uffffffff' UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character >>> u'\Ufffffffe' UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character and doesn't change the outcome of the test suite. Patch against 2.3.1 attached. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-10-06 05:08 Message: Logged In: YES user_id=31392 Fixed in rev. 2.199 of unicodeobject.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817156&group_id=5470 From noreply at sourceforge.net Mon Oct 6 01:42:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 6 01:42:22 2003 Subject: [Python-bugs-list] [ python-Bugs-817156 ] invalid \U escape gives 0=length unistr Message-ID: Bugs item #817156, was opened at 2003-10-03 23:30 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817156&group_id=5470 Category: Unicode Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Jeff Epler (jepler) Assigned to: M.-A. Lemburg (lemburg) Summary: invalid \U escape gives 0=length unistr Initial Comment: >>> u'\Ufffffffe' # CORRECT UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character >>> u'\Uffffffff' # WRONG u'' >>> len(_) 0 Observed on 2.2.2 (redhat wide-unicode build, sys.maxunicode=1114111), 2.3.1 (custom build, sys.maxunicode == 65535) I think the problem is due to this logic in unicodeobject.c:PyUnicode_DecodeUnicodeEscape() if (chr == 0xffffffff) /* _decoding_error will have already written into the target buffer. */ break; perhaps it should be (chr == 0xffffffff && PyErr_Occurred()) I tried this change locally, and it fixes the problem: >>> u'\Uffffffff' UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character >>> u'\Ufffffffe' UnicodeDecodeError: 'unicodeescape' codec can't decode bytes in position 0-9: illegal Unicode character and doesn't change the outcome of the test suite. Patch against 2.3.1 attached. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-06 15:42 Message: Logged In: YES user_id=29957 This should probably be fixed in release23-maint as well, no? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-10-06 15:08 Message: Logged In: YES user_id=31392 Fixed in rev. 2.199 of unicodeobject.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817156&group_id=5470 From noreply at sourceforge.net Mon Oct 6 04:03:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 6 04:03:33 2003 Subject: [Python-bugs-list] [ python-Bugs-818490 ] socketmodule.c compile error using SunPro cc Message-ID: Bugs item #818490, was opened at 2003-10-06 03: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=818490&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rick Ratzel (rlratzel) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c compile error using SunPro cc Initial Comment: If the _socket module is to be included in libpython.a rather than built as a shared lib (by specifying it in Modules/Setup.local under a *static* line), compile errors result on SunOS 5.7 using the Sun WorkShop 6 compiler. Undefined symbol "AF_INET6" on line 2972 and undefined symbol "INET_ADDRSTRLEN" on 3016 are a few of the errors...please see the attached output file. Note that the configure process completed successfully. Here is some additional info: Python version: 2.3.2 "uname -a" output: SunOS blueberry 5.7 Generic_106541-15 sun4u sparc SUNW,Ultra-60 compiler version: Sun WorkShop 6 update 1 C 5.2 2000/09/11 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818490&group_id=5470 From noreply at sourceforge.net Mon Oct 6 05:39:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 6 05:39:54 2003 Subject: [Python-bugs-list] [ python-Feature Requests-813922 ] Zero Configuration Networking? Message-ID: Feature Requests item #813922, was opened at 2003-09-28 11:12 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=813922&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus Elfring (elfring) Assigned to: Nobody/Anonymous (nobody) Summary: Zero Configuration Networking? Initial Comment: Would you like to support this proposed standard? 1. http://www.zeroconf.org/ 2. http://www.ietf.org/html.charters/zeroconf- charter.html 3. http://citeseer.org/cs?q=Zero+Configuration+Networking 4. http://www.oreillynet.com/pub/wlg/3137 5. http://www.spack.org/index.cgi/ZeroConf 6. http://sourceforge.net/projects/zeroconf/ 7. http://sourceforge.net/projects/howl/ 8. http://www.uow.edu.au/~dfs/projects/2003/projects2003.html 9. http://www.apple.com/macosx/jaguar/rendezvous.html 10. http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/NetServices/Concepts/AboutRendezvous.html 11. http://developer.apple.com/darwin/projects/rendezvous/ 12. http://www.neato.org/~femur/iu/ 13. http://homepage.mac.com/macdomeeu/dev/current/mod_rendezvous/ 14. http://www.macdevcenter.com/pub/a/mac/2003/04/08/mod_rendezvous.html 15. http://groups.google.de/groups?selm=40ed1d8f.0309272247.58b3abbc%40posting.google.com ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-10-06 11:39 Message: Logged In: YES user_id=45365 You'll have to be a bit more specific as to which bits you want to be supported by Python, and how. Python seems to work fine with Apple's Rendezvous implementation, at least at the level at which I've tried it. But that's using Python in a client application, I haven't used it for a server. But advertising services requires OS-specific API's, I think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=813922&group_id=5470 From noreply at sourceforge.net Mon Oct 6 06:08:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 6 06:08:26 2003 Subject: [Python-bugs-list] [ python-Bugs-816946 ] Float Multiplication Message-ID: Bugs item #816946, was opened at 2003-10-03 05:09 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816946&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Victor Demaria (vktor) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Float Multiplication Initial Comment: Why (1.16 * 100) is not the same than (1.16 * 10 * 10)? I tried 1.16*100. also and it is = 115.99999999; but if I do 1.16*10*10 I get 116. Thanks.... ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-06 11:07 Message: Logged In: YES user_id=6656 Close again. ---------------------------------------------------------------------- Comment By: Victor Demaria (vktor) Date: 2003-10-04 03:06 Message: Logged In: YES user_id=879316 This is not a bug. Binary floating point cannot represent decimal fractions exactly, so some rounding always occurs (even in Python 1.5.2). What changed is that Python 2.0 shows more precision than before in certain circumstances (repr() and the interactive prompt). You can use str() or print to get the old, rounded output: >>> print 0.1+0.1 0.2 >>> Follow the link for more information: http://www.python.org/doc/2.2.1/tut/node14.html ---------------------------------------------------------------------- Comment By: Victor Demaria (vktor) Date: 2003-10-04 03:06 Message: Logged In: YES user_id=879316 I'sorry, but I don't agree... Even 3.13 (3.1299999999999999) * 100 is 313 = like 3.13*10*10 (3.13*100=3.13*10*10) In this case 1.16*100 <> 1.16*10*10 Sorry again, but it is a huge difference when you do int (1.16*100)=115 or you do int(1.16*10*10)=116 Thanks... ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-10-03 08:48 Message: Logged In: YES user_id=38376 The answer to your question can be found in the Python tutorial, and has nothing to do with regular expressions: http://www.python.org/doc/tut/node14.html Please don't use the bug tracker to ask for help in the future; I suggest asking on comp.lang.python (for other help forums, see www.python.org). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816946&group_id=5470 From noreply at sourceforge.net Mon Oct 6 09:33:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 6 09:33:33 2003 Subject: [Python-bugs-list] [ python-Bugs-818065 ] mailbox._Subfile readline() bug Message-ID: Bugs item #818065, was opened at 2003-10-05 11:09 Message generated for change (Comment added) made by jbperez808 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818065&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jonathan Perez (jbperez808) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox._Subfile readline() bug Initial Comment: mailbox._Subfile's readline() will chop off the first character of the next line when reading Unix-style terminated files. It's surprising no one has mentioned this before. The problem lies in line mailbox._Subfile.readline() itself where self.pos is assigned self.fp.tell()'s value. You will need to subtract 1 from self.pos if a file uses unix-style termination. ---------------------------------------------------------------------- >Comment By: Jonathan Perez (jbperez808) Date: 2003-10-06 13:33 Message: Logged In: YES user_id=286435 There doesn't seem to be a clean way to fix the code. But there is a rather satisfactory workaround: Open the mbox file in binary mode for Unix (and Mac?) style terminated files. This should DEFINITELY be mentioned in the mailbox module docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818065&group_id=5470 From noreply at sourceforge.net Mon Oct 6 11:38:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 6 11:39:58 2003 Subject: [Python-bugs-list] [ python-Bugs-818029 ] installer wakes up Windows File Protection Message-ID: Bugs item #818029, was opened at 2003-10-05 10:49 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pete (thegoldenear) Assigned to: Thomas Heller (theller) Summary: installer wakes up Windows File Protection Initial Comment: installing Python 2.3.2 on Windows 2000 SP4 induced the Windows File Protection, presumably bcos an existing system file had been replaced by an older version ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-10-06 17:38 Message: Logged In: YES user_id=11105 I *can* reproduce it - look into the event viewer, category 'System': File replacement was attempted on the protected system file d:\winnt\system32\msvcirt.dll... The windows installer tries (in my case) to replace the version 6.1.8637.0 with 7.0.2600.0. Looking at python23.dll's dependencies with Dependency Walker, it seems that msvcirt.dll isn't required by Python at all, so the solution would be simple: leave msvcirt.dll out of the installer. Why is it in the installer at all? Tim? ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-10-05 23:21 Message: Logged In: YES user_id=699438 I couldn't reproduce this on a stock install of W2K SP 4. If you're in a position to do so (you'll need the physical CD media), could you rebuild your DLL cache? From the command-line "sfc /purgecache && sfc /scannow" should do this. After that, try to install python2.3.2 and see if sfc kicks in again. If you can't do that, you might want to see if the file python23.dll somehow manually ended up in the %windir% \system32\dllcache directory. As far as I know, thats the only file that should be getting shoved into an area the sfc cares about. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-05 20:12 Message: Logged In: YES user_id=31435 Changed category to Windows and assigned to Thomas Heller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 From noreply at sourceforge.net Mon Oct 6 11:50:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 6 11:52:11 2003 Subject: [Python-bugs-list] [ python-Bugs-818029 ] installer wakes up Windows File Protection Message-ID: Bugs item #818029, was opened at 2003-10-05 04:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pete (thegoldenear) >Assigned to: Mark Hammond (mhammond) Summary: installer wakes up Windows File Protection Initial Comment: installing Python 2.3.2 on Windows 2000 SP4 induced the Windows File Protection, presumably bcos an existing system file had been replaced by an older version ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-06 11:50 Message: Logged In: YES user_id=31435 msvcirt.dll was in the installer when I inherited it from Guido. He probably inherited it from Mark (Hammond). If Mark can't remember why it's there either, we should check all the .pyd (not just python23.dll) for references to it. Assigned to Mark. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-06 11:38 Message: Logged In: YES user_id=11105 I *can* reproduce it - look into the event viewer, category 'System': File replacement was attempted on the protected system file d:\winnt\system32\msvcirt.dll... The windows installer tries (in my case) to replace the version 6.1.8637.0 with 7.0.2600.0. Looking at python23.dll's dependencies with Dependency Walker, it seems that msvcirt.dll isn't required by Python at all, so the solution would be simple: leave msvcirt.dll out of the installer. Why is it in the installer at all? Tim? ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-10-05 17:21 Message: Logged In: YES user_id=699438 I couldn't reproduce this on a stock install of W2K SP 4. If you're in a position to do so (you'll need the physical CD media), could you rebuild your DLL cache? From the command-line "sfc /purgecache && sfc /scannow" should do this. After that, try to install python2.3.2 and see if sfc kicks in again. If you can't do that, you might want to see if the file python23.dll somehow manually ended up in the %windir% \system32\dllcache directory. As far as I know, thats the only file that should be getting shoved into an area the sfc cares about. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-05 14:12 Message: Logged In: YES user_id=31435 Changed category to Windows and assigned to Thomas Heller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 From noreply at sourceforge.net Mon Oct 6 16:40:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 6 16:40:52 2003 Subject: [Python-bugs-list] [ python-Bugs-818861 ] ConfigParser items() inconsistency Message-ID: Bugs item #818861, was opened at 2003-10-06 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=818861&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: ConfigParser items() inconsistency Initial Comment: The RawConfigParser.items() method returns a list while ConfigParser.items() and SafeConfigParser.items() return generators. This inconsistency within the module is a distraction. Reported by Gordon Williams on python-dev. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818861&group_id=5470 From noreply at sourceforge.net Mon Oct 6 19:02:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 6 19:02:33 2003 Subject: [Python-bugs-list] [ python-Bugs-815646 ] thread unsafe file objects cause crash Message-ID: Bugs item #815646, was opened at 2003-09-30 23:22 Message generated for change (Comment added) made by janixia You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815646&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jan Olderdissen (janixia) Assigned to: Nobody/Anonymous (nobody) Summary: thread unsafe file objects cause crash Initial Comment: Note: This may be a dupe or a generalization of 595601. Running below code snippet on 2.3.1 release and debug build on Windows 2000/XP a few times will inevitably lead to a crash. 2.2.2 also exhibits this behavior. The crashing code: ------------ import thread f=open("tmp1", "w") def worker(): global f while 1: f.close() f=open("tmp1", "w") f.seek (0, 0) thread.start_new_thread(worker, ()) thread.start_new_thread(worker, ()) while 1: pass ------------- The issue appears to be this (and similar) code sections from fileobject.c: Py_BEGIN_ALLOW_THREADS errno = 0; ret = _portable_fseek(f->f_fp, offset, whence); Py_END_ALLOW_THREADS Note that due to Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS, f->f_fp can be set to NULL by file_close prior to entering _portable_fseek. Similar crashes can be observed with read, write and close itself when they are mixed with a concurrent close. Obviously, the offending python code is buggy and a lock should be used to prevent concurrent access to f. However, it seems unreasonable for Python to crash because of it. A mutex preventing concurrent access to the file object seems like a reasonable way to fix this. ---------------------------------------------------------------------- >Comment By: Jan Olderdissen (janixia) Date: 2003-10-06 16:02 Message: Logged In: YES user_id=877914 I'm inclined to go with Shane's suggested solution of reference counting when file access is in progress. It requires no synchronisation (increment, decrement and check are outside global lock release) and should have the smallest performance impact. I don't think the FILE * extraction problem can be solved at all. Once the horse it out of the barn... However, for the "standard" case Shane's suggestion provides a neat and clean solution for the problem. If the community can agree on this solution, I could be talked into implementing it. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-10-05 20:48 Message: Logged In: YES user_id=31392 Patch 595601 is an attempt to address this problem, but it's incomplete. The file object API allows an extension to extract to FILE * and squirrel it away. That's clearly unsafe, because it can't participate in a locking scheme without re-writing extensions. Shane Hathaway proposed another solution here: http://mail.python.org/pipermail/python-dev/2003-June/036543.html The problem in this case is that we cause the call to close() to raise an exception. I'd prefer to see the exception raised elsewhere, because close() seldom fails and is often closed from routines that are cleaning up at the end. On the other hand, this solution would be easier to implementation, so I'm at least +0 on it. Let's do one or the other. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-04 01:01 Message: Logged In: YES user_id=21627 janixia, don't worry about the formatting - this is partially SF's fault, too. Would you be interested in developing and testing a patch? I think it would be sufficient to move the f->f_fp access out of the GIL releasage. ---------------------------------------------------------------------- Comment By: Jan Olderdissen (janixia) Date: 2003-10-01 00:08 Message: Logged In: YES user_id=877914 My apologies for the mangled source. I suppose there isn't a way for me to remedy the situation. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 00:03 Message: Logged In: YES user_id=29957 Attaching the failing code as an attachment, because SF mangles source code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815646&group_id=5470 From noreply at sourceforge.net Tue Oct 7 06:09:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 06:09:16 2003 Subject: [Python-bugs-list] [ python-Feature Requests-813922 ] Zero Configuration Networking? Message-ID: Feature Requests item #813922, was opened at 2003-09-28 11:12 Message generated for change (Comment added) made by elfring You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=813922&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus Elfring (elfring) >Assigned to: Jack Jansen (jackjansen) Summary: Zero Configuration Networking? Initial Comment: Would you like to support this proposed standard? 1. http://www.zeroconf.org/ 2. http://www.ietf.org/html.charters/zeroconf- charter.html 3. http://citeseer.org/cs?q=Zero+Configuration+Networking 4. http://www.oreillynet.com/pub/wlg/3137 5. http://www.spack.org/index.cgi/ZeroConf 6. http://sourceforge.net/projects/zeroconf/ 7. http://sourceforge.net/projects/howl/ 8. http://www.uow.edu.au/~dfs/projects/2003/projects2003.html 9. http://www.apple.com/macosx/jaguar/rendezvous.html 10. http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/NetServices/Concepts/AboutRendezvous.html 11. http://developer.apple.com/darwin/projects/rendezvous/ 12. http://www.neato.org/~femur/iu/ 13. http://homepage.mac.com/macdomeeu/dev/current/mod_rendezvous/ 14. http://www.macdevcenter.com/pub/a/mac/2003/04/08/mod_rendezvous.html 15. http://groups.google.de/groups?selm=40ed1d8f.0309272247.58b3abbc%40posting.google.com ---------------------------------------------------------------------- >Comment By: Markus Elfring (elfring) Date: 2003-10-07 12:09 Message: Logged In: YES user_id=572001 12. Can the Java based ZMAAP implementation be used by python? Would you like to add a package for this API and Multicast DNS? http://www1.ietf.org/mail-archive/ietf- announce/Current/msg12884.html http://www.dns-sd.org/ ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-10-06 11:39 Message: Logged In: YES user_id=45365 You'll have to be a bit more specific as to which bits you want to be supported by Python, and how. Python seems to work fine with Apple's Rendezvous implementation, at least at the level at which I've tried it. But that's using Python in a client application, I haven't used it for a server. But advertising services requires OS-specific API's, I think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=813922&group_id=5470 From noreply at sourceforge.net Tue Oct 7 06:18:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 06:18:57 2003 Subject: [Python-bugs-list] [ python-Feature Requests-813922 ] Zero Configuration Networking? Message-ID: Feature Requests item #813922, was opened at 2003-09-28 11:12 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=813922&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus Elfring (elfring) >Assigned to: Nobody/Anonymous (nobody) Summary: Zero Configuration Networking? Initial Comment: Would you like to support this proposed standard? 1. http://www.zeroconf.org/ 2. http://www.ietf.org/html.charters/zeroconf- charter.html 3. http://citeseer.org/cs?q=Zero+Configuration+Networking 4. http://www.oreillynet.com/pub/wlg/3137 5. http://www.spack.org/index.cgi/ZeroConf 6. http://sourceforge.net/projects/zeroconf/ 7. http://sourceforge.net/projects/howl/ 8. http://www.uow.edu.au/~dfs/projects/2003/projects2003.html 9. http://www.apple.com/macosx/jaguar/rendezvous.html 10. http://developer.apple.com/techpubs/macosx/Cocoa/TasksAndConcepts/ProgrammingTopics/NetServices/Concepts/AboutRendezvous.html 11. http://developer.apple.com/darwin/projects/rendezvous/ 12. http://www.neato.org/~femur/iu/ 13. http://homepage.mac.com/macdomeeu/dev/current/mod_rendezvous/ 14. http://www.macdevcenter.com/pub/a/mac/2003/04/08/mod_rendezvous.html 15. http://groups.google.de/groups?selm=40ed1d8f.0309272247.58b3abbc%40posting.google.com ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-10-07 12:18 Message: Logged In: YES user_id=45365 Please don't assign this to me: I'm not going to do the work, I'm just trying to get information from you. If there is specific functionality you want: state it clearly. If it really deserves to be in _socket or some other standard Lib place and you provide good reasons it may get added. The chance of it getting added would increase immensely if you added a working patch:-) If this is a large API that pertains only to zeroconf it should be an extension package, and not part of the core. In that case it's probably best to round up some people at comp.lang.python and team up to write that package. ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2003-10-07 12:09 Message: Logged In: YES user_id=572001 12. Can the Java based ZMAAP implementation be used by python? Would you like to add a package for this API and Multicast DNS? http://www1.ietf.org/mail-archive/ietf- announce/Current/msg12884.html http://www.dns-sd.org/ ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-10-06 11:39 Message: Logged In: YES user_id=45365 You'll have to be a bit more specific as to which bits you want to be supported by Python, and how. Python seems to work fine with Apple's Rendezvous implementation, at least at the level at which I've tried it. But that's using Python in a client application, I haven't used it for a server. But advertising services requires OS-specific API's, I think? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=813922&group_id=5470 From noreply at sourceforge.net Tue Oct 7 06:47:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 06:47:02 2003 Subject: [Python-bugs-list] [ python-Bugs-819178 ] optparse "append" action should always make the empty list. Message-ID: Bugs item #819178, was opened at 2003-10-07 06: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=819178&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: optparse "append" action should always make the empty list. Initial Comment: I was torn between "Bug" and "RFE" on this one. Anyway, with options whose action is "append", optparse.OptionParser will set the option to None if it's never called. Instead, I think it should set the option to the empty list, so code can iterate over the list regardless of whether the option was ever given. It keeps users from having to guard their iteration with "if options.foo:" Such a change would be slightly backwards-incompatible; users who use "if option.foo is None:" form instead of just "if not options.foo:" would run into trouble, as well as those users who used an "else" statement in their loops. The latter seemed like a big problem, until I realized that those users' code *already* guards against the empty case, and thus shouldn't run into difficulties. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819178&group_id=5470 From noreply at sourceforge.net Tue Oct 7 06:47:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 06:47:55 2003 Subject: [Python-bugs-list] [ python-Bugs-819178 ] optparse "append" action should always make the empty list. Message-ID: Bugs item #819178, was opened at 2003-10-07 06:47 Message generated for change (Settings changed) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819178&group_id=5470 Category: None >Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: optparse "append" action should always make the empty list. Initial Comment: I was torn between "Bug" and "RFE" on this one. Anyway, with options whose action is "append", optparse.OptionParser will set the option to None if it's never called. Instead, I think it should set the option to the empty list, so code can iterate over the list regardless of whether the option was ever given. It keeps users from having to guard their iteration with "if options.foo:" Such a change would be slightly backwards-incompatible; users who use "if option.foo is None:" form instead of just "if not options.foo:" would run into trouble, as well as those users who used an "else" statement in their loops. The latter seemed like a big problem, until I realized that those users' code *already* guards against the empty case, and thus shouldn't run into difficulties. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819178&group_id=5470 From noreply at sourceforge.net Tue Oct 7 06:48:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 06:48:55 2003 Subject: [Python-bugs-list] [ python-Bugs-819178 ] optparse "append" action should always make the empty list. Message-ID: Bugs item #819178, was opened at 2003-10-07 06:47 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819178&group_id=5470 Category: None >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: optparse "append" action should always make the empty list. Initial Comment: I was torn between "Bug" and "RFE" on this one. Anyway, with options whose action is "append", optparse.OptionParser will set the option to None if it's never called. Instead, I think it should set the option to the empty list, so code can iterate over the list regardless of whether the option was ever given. It keeps users from having to guard their iteration with "if options.foo:" Such a change would be slightly backwards-incompatible; users who use "if option.foo is None:" form instead of just "if not options.foo:" would run into trouble, as well as those users who used an "else" statement in their loops. The latter seemed like a big problem, until I realized that those users' code *already* guards against the empty case, and thus shouldn't run into difficulties. ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-07 06:48 Message: Logged In: YES user_id=99508 So, I *thought* I could change this to an RFE after submitting it, but apparently not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819178&group_id=5470 From noreply at sourceforge.net Tue Oct 7 15:32:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 15:32:33 2003 Subject: [Python-bugs-list] [ python-Bugs-819510 ] httplib.SSLFile lacks readlines() method Message-ID: Bugs item #819510, was opened at 2003-10-07 14: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=819510&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Campbell (mattcamp) Assigned to: Nobody/Anonymous (nobody) Summary: httplib.SSLFile lacks readlines() method Initial Comment: The httplib.SSLFile class has no readlines() method. A readlines() method is necessary if the SSL server sends back an HTTP/0.9 response, since in that case, the httplib.LineAndFileWrapper class is used. The_done () method in httplib.LineAndFileWrapper has this statement: self.readlines = self._file.readlines Which causes an error when "self._file" refers to SSLFile. This happens even if I only call the read() method on LineAndFileWrapper. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819510&group_id=5470 From noreply at sourceforge.net Tue Oct 7 16:05:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 7 16:05:12 2003 Subject: [Python-bugs-list] [ python-Bugs-816929 ] term.h present but cannot be compiled Message-ID: Bugs item #816929, was opened at 2003-10-03 15:09 Message generated for change (Comment added) made by nhawthorn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816929&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nicholas Hawthorn (nhawthorn) Assigned to: Nobody/Anonymous (nobody) Summary: term.h present but cannot be compiled Initial Comment: This report relates to building Python 2.3.1 on Irix 6.5. Here is stderr output from: configure --with-cxx=CC configure: WARNING: term.h: present but cannot be compiled configure: WARNING: term.h: check for missing prerequisite headers? configure: WARNING: term.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## I did submit a bug report -- they said the issue is known. "make" after this gave the following error, among others:- cc-1059 cc: ERROR File = /xlv4/med_psyc/nhn/py231/Python-2.3.1/Modules/termios.c , Line = 633 A function call is not allowed in a constant expression. {"CWERASE", CWERASE}, By experiment on a very short C program, term.h needs curses.h to be included before it, and will not compile correctly otherwise. This would give a number of errors. Thanks and best wishes! ---------------------------------------------------------------------- >Comment By: Nicholas Hawthorn (nhawthorn) Date: 2003-10-08 09:05 Message: Logged In: YES user_id=879291 I can't properly understand the error or suggest a patch, after trying for quite a long time. Compiling --without-cxx did not help. I did find out that CWERASE is meant to expand to CTRL('w') which is meant to expand to (('w')&037). There are #defines to do this in /usr/include/sys/termios.h, and for things like CWERASE, but they are controlled by #if statements. I agree that there could be problems with SGI system header files, but it would be nice if Python allowed for these. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-04 19:58 Message: Logged In: YES user_id=21627 Even though I cannot fully understand your remarks, it appears that you are suggesting a solution. Can you perhaps produce a patch that fixes the problem? I am still uncertain what the bug in Python here is. In line 633, there is no function call, as far as I can see (although CWERASE might expand to a function call); so it seems more likely that this is a bug in CC or in the system header files, not in Python. As a work-around, just try compiling --without-cxx. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816929&group_id=5470 From noreply at sourceforge.net Wed Oct 8 04:30:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 8 04:31:18 2003 Subject: [Python-bugs-list] [ python-Bugs-815753 ] SCO_SV: many modules cannot be imported Message-ID: Bugs item #815753, was opened at 2003-10-01 12:31 Message generated for change (Comment added) made by eurosys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (eurosys) Assigned to: Michael Hudson (mwh) Summary: SCO_SV: many modules cannot be imported Initial Comment: Trying to execute the makefile for Python 2.3.1 and 2.3. 2c on an SCO-box results in a lot of warnings like: *** WARNING: importing extension "struct" failed with exceptions.AttributeError: 'module' object has no attribute 'load_dynamic' This results in not being able to import the struct (and many others) module in the Python interpreter: Python 2.3.2c1 (#7, Oct 1 2003, 12:08:43) [C] on sco_sv3 Type "help", "copyright", "credits" or "license" for more information. >>> import struct Traceback (most recent call last): File "", line 1, in ? ImportError: No module named struct See the attached make.out file, which includes the generated makefile for my system, followed by the output sent to stdout. Installing Python 2.2.3 went almost flawless. >uname -X System = SCO_SV Node = ontwik2 Release = 3.2v5.0.5 KernelID = 98/07/02 Machine = i80386 BusType = ISA Serial = 5FL004745 Users = 30-user OEM# = 0 Origin# = 1 NumCPU = 2 ---------------------------------------------------------------------- >Comment By: Roger Erens (eurosys) Date: 2003-10-08 10:30 Message: Logged In: YES user_id=878033 Alas, I cannot confirm this one. See the attached output. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 19:22 Message: Logged In: YES user_id=21627 eurosys, can you confirm that config-hack-2.diff fixes your problem as well? I recommend integration of that change in both 2.4 and 2.3; if it causes problems on some system, we should have time before 2.3.3 to correct them. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 16:20 Message: Logged In: YES user_id=6656 Something like the attached? It's impressively vile, but it doesn't seem to break anything on linux. I'm not quite sure what gyrations people expect this machinery to withstand, though... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 16:09 Message: Logged In: YES user_id=21627 Yes, setting CFLAGS appears to be the only way to achieve that. There is also the issue of the user setting CFLAGS before configure starts; traditionally, these should get incorporated into both configure tests, and the final build process. So something like # early BASECFLAGS=$CFLAGS # after each block changing either BASECFLAGS or OPT CFLAGS=$BASECFLAGS $OPT might work (unless the user selects a flag that contradicts with one set in BASECFLAGS) ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 15:37 Message: Logged In: YES user_id=6656 Agree that would be nice, but how do you do arrange for that for the tests run by, e.g., AC_CHECK_FUNCS? Seems to me you have to add it to CFLAGS to make that happen... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:26 Message: Logged In: YES user_id=21627 I agree it is a hack. Without testing anything right know, I think all configure tests should run with BASECFLAGS. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 14:49 Message: Logged In: YES user_id=6656 Glad to have my suspicions confirmed! The reason my patch was a hack is that it patches up SCO ok, but this is at least potentially a problem on other platforms. Given the lack of similar bug reports, though, perhaps it isn't. The remaining warnings look like different issues; should they become bothering I recommend opening new reports. Assigning to Martin, 'cause I'd like him to read my comment of 2003-10-03 12:17 before I check anything in (we missed 2.3.2, and I don't think 2.3.3 will be for a while). ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-03 14:37 Message: Logged In: YES user_id=878033 Hi Michael, nice hack for a first time: no warnings this time, as you can see in the attached make.out. Thanks a lot! Only a few compiler errors remain, but I cannot be bothered with them right now. So just FYI (after running make; make clean): >make > make.out "Objects/stringobject.c", line 1765: warning: statement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/getaddrinfo.c", line 556: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/getnameinfo.c", line 184: error: undefine d symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2374: error: undefi ned symbol: h_errno "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 2972: error: undefi ned symbol: AF_INET6 "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: undefi ned symbol: INET_ADDRSTRLEN "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3016: error: integr al constant expression expected "/usrdir/rogere/Python-2.3.2c1/Modules/socketmodule.c", line 3055: warning: stat ement not reached "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1553: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1554: warning: arg ument is incompatible with prototype: arg #1 "/usrdir/rogere/Python-2.3.2c1/Modules/_cursesmodule.c", line 1964: warning: ass ignment type mismatch ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-03 13:17 Message: Logged In: YES user_id=6656 Curioser and curioser. The difference seems to be that configure for 2.2.3 passes "-belf" to cc when checking for dlopen but configure for 2.3 doesn't. I actually have an idea how this happens: in 2.3, the CFLAGS variable was split up into BASECFLAGS and OPT. We know we need -belf on SCO, so we stuff that into BASECFLAGS. However, this *doesn't* make the rest of the configure tests use -belf -- result breakage. (Martin, are you reading this? Does this sound reasonable?) Roger, can you try the attached patch? It's a bit of a hack... ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-03 00:25 Message: Logged In: YES user_id=878033 I uploaded both the config.log and the pyconfig.h for 2.2.3. I'm curious what you think of it. The system is quite old, indeed (but we have even older among our customer base, as they are not very much inclined to investing in hardware!). It is much used, though. Regards, Roger ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 18:19 Message: Logged In: YES user_id=6656 Can you attach the config.log for 2.2.3? I'm now a little curious as to how dynamic linking ever worked on this system (which is fairly old, right?) ---------------------------------------------------------------------- Comment By: Roger Erens (eurosys) Date: 2003-10-01 17:45 Message: Logged In: YES user_id=878033 Got to go home now. Hope I can help you further tomorrow. -RE- ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 17:34 Message: Logged In: YES user_id=29957 Hm. mwh is right - it seems like HAVE_DYNAMIC_LOADING isn't being defined. Could you also attach the files configure.log and pyconfig.h from the 2.3 build? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-01 17:10 Message: Logged In: YES user_id=6656 It looks like the module 'imp' is messed up. That's strange. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-01 16:43 Message: Logged In: YES user_id=29957 Ugh. I don't have access to any SCO boxes to debug this. Could you rebuild Python 2.2 on the same platform and attach the output (as you did for 2.3). Obviously something's changed in how we invoke the dynamic linker or some such. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815753&group_id=5470 From noreply at sourceforge.net Wed Oct 8 05:57:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 8 05:58:01 2003 Subject: [Python-bugs-list] [ python-Bugs-819860 ] PythonIDE interactive window Unicode bug Message-ID: Bugs item #819860, was opened at 2003-10-08 09:57 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=819860&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jurjen N.E. Bos (jneb) Assigned to: Jack Jansen (jackjansen) Summary: PythonIDE interactive window Unicode bug Initial Comment: Platform: OS X 10.2.8 Python 2.3 final, running PythonIDE, but I guess the bug is also in 2.3.2. In the "Python Interactive" window (characters between acute brackets to be interpreted by humans): >>> print "" >>> print u"" That's not bad, because it cannot be printed in ASCII. Fine. But now, at every CR, the dialog opens again! The same problem when running code in an edit window; there you get in a state that any print command gives this error. I managed to fix it, but I am not so sure this is the right way to do it. I changed PyConsole.ConsoleTextWidget.flush: There are two lines (that are not together, but can safely be moved together) self.ted.WEInsert(stuff, None, None) self._buf = "" and I replaced this by try: self.ted.WEInsert(stuff, None, None) finally: self._buf = "" The same code occurs in PyConsole.PyOutput.flush(); this fixes the bug in the other case. - Jurjen ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819860&group_id=5470 From noreply at sourceforge.net Wed Oct 8 06:49:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 8 06:49:28 2003 Subject: [Python-bugs-list] [ python-Bugs-819860 ] PythonIDE interactive window Unicode bug Message-ID: Bugs item #819860, was opened at 2003-10-08 11:57 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819860&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jurjen N.E. Bos (jneb) >Assigned to: Just van Rossum (jvr) Summary: PythonIDE interactive window Unicode bug Initial Comment: Platform: OS X 10.2.8 Python 2.3 final, running PythonIDE, but I guess the bug is also in 2.3.2. In the "Python Interactive" window (characters between acute brackets to be interpreted by humans): >>> print "" >>> print u"" That's not bad, because it cannot be printed in ASCII. Fine. But now, at every CR, the dialog opens again! The same problem when running code in an edit window; there you get in a state that any print command gives this error. I managed to fix it, but I am not so sure this is the right way to do it. I changed PyConsole.ConsoleTextWidget.flush: There are two lines (that are not together, but can safely be moved together) self.ted.WEInsert(stuff, None, None) self._buf = "" and I replaced this by try: self.ted.WEInsert(stuff, None, None) finally: self._buf = "" The same code occurs in PyConsole.PyOutput.flush(); this fixes the bug in the other case. - Jurjen ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-10-08 12:49 Message: Logged In: YES user_id=45365 Just, could you take a look at this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819860&group_id=5470 From noreply at sourceforge.net Wed Oct 8 19:39:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 8 19:39:37 2003 Subject: [Python-bugs-list] [ python-Bugs-820344 ] Ref Man Index: Symbols -- Latex leak Message-ID: Bugs item #820344, was opened at 2003-10-08 19: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=820344&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Terry J. Reedy (tjreedy) Assigned to: Nobody/Anonymous (nobody) Summary: Ref Man Index: Symbols -- Latex leak Initial Comment: Current online Ref Manual, Index, Symbols section has following text which looks like untranslated Latex: \textttNone object \textttNotImplemented object ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820344&group_id=5470 From noreply at sourceforge.net Wed Oct 8 22:34:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 8 22:34:39 2003 Subject: [Python-bugs-list] [ python-Bugs-820397 ] __nonzero__() returns 1/0 Message-ID: Bugs item #820397, was opened at 2003-10-09 11:34 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=820397&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: __nonzero__() returns 1/0 Initial Comment: This is similar to Patch [820195]. http://www.python.org/sf/820195 number.__nonzero__() returns 1/0, while number != 0 returns True/False. >>> n = 1 >>> n.__nonzero__() 1 >>> n != 0 True >>> n = 0 >>> n.__nonzero__() 0 >>> n != 0 False >>> c = 1+1j >>> c.__nonzero__() 1 >>> c != 0 True >>> c = 0j >>> c.__nonzero__() 0 >>> c != 0 False ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820397&group_id=5470 From noreply at sourceforge.net Thu Oct 9 08:11:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 9 08:12:02 2003 Subject: [Python-bugs-list] [ python-Bugs-820583 ] urllib2 silently returns None when auth_uri is mismatched Message-ID: Bugs item #820583, was opened at 2003-10-09 07: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=820583&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christopher Armstrong (radeex) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 silently returns None when auth_uri is mismatched Initial Comment: Code like the following, where the `uri' argument which I pass to add_password is not actually the URI that the web server gives me in its request for basic auth, makes the return value of OpenDirector.open None. This is either a code bug or a documentation bug. I expected director.open to raise an error, but saying something like "open will return None in these cases: ...." would also be a valid solution, if one that's not as good, IMO... the AuthHandler could raise an error once it realizes that none of the URIs we have match, perhaps? import urllib2 realm = "Linksys BEFW11S4 V4" passman = urllib2.HTTPPasswordMgr() passman.add_password(realm, 'NOT_WHAT_THE_SERVER_GIVES_ME', 'user', 'password') auther = urllib2.HTTPBasicAuthHandler(passman) getter = urllib2.HTTPHandler() director = urllib2.OpenerDirector() director.add_handler(auther) director.add_handler(getter) f = director.open('http://192.168.1.1/Status.htm') print f, "is None" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820583&group_id=5470 From noreply at sourceforge.net Thu Oct 9 09:15:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 9 09:15:26 2003 Subject: [Python-bugs-list] [ python-Bugs-820605 ] tkinter's 'after' and 'threads' on multiprocessor Message-ID: Bugs item #820605, was opened at 2003-10-09 15: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=820605&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Zoran Bosnjak (zoranbosnjak) Assigned to: Martin v. L?wis (loewis) Summary: tkinter's 'after' and 'threads' on multiprocessor Initial Comment: I have attached simple testfile which works fine on single processor machine, but it does not work on multiprocessor machine (dual XEON - HT 2x 2.4GHz, python 2.1.1 (or python 2.2), RedHat 9.0 distr., linux-kernel 2.4.20-20-9smp). At the moment I can not tell where the problem is. It could be - in python core, - in threading module - in tkinter, TCL, Tk - in linux kernel Problem description: - I use tkinter's (Tk's) after method for periodic calls - I also start a few dummy threads which have nothong to do with tkinter. - (see the attached file) - After a while, one or more threads stop running and 'after' method stops working (they simply block). The situation is different each time I run the script. The problem is random and probability raises with number of threads. Normaly the problem occours after a few seconds with 8 threads. I am willing to run additional tests if someone has any idea where to start debugging. regards, Zoran Bosnjak ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820605&group_id=5470 From noreply at sourceforge.net Thu Oct 9 19:13:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 9 19:13:17 2003 Subject: [Python-bugs-list] [ python-Bugs-820953 ] dbm Error Message-ID: Bugs item #820953, was opened at 2003-10-09 16: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=820953&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Gifford (giffordj) Assigned to: Nobody/Anonymous (nobody) Summary: dbm Error Initial Comment: Receive the following error during make install of python 2.3.2. Any suggestions or is it safe to ignore. building 'dbm' extension gcc -pthread -DNDEBUG -g -march=pentium2 -mmmx - O2 -pipe -Wall -Wstrict-prototypes -fPIC -fno-strict- aliasing -DHAVE_NDBM_H -I. -I/usr/src/Python- 2.3.2/./Include -I/usr/local/include -I/usr/src/Python- 2.3.2/Include -I/usr/src/Python-2.3.2 - c /usr/src/Python-2.3.2/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o gcc -pthread -shared build/temp.linux-i686- 2.3/dbmmodule.o -L/usr/local/lib -o build/lib.linux-i686- 2.3/dbm.so *** WARNING: renaming "dbm" since importing it failed: build/lib.linux-i686-2.3/dbm.so: undefined symbol: dbm_firstkey running build_scripts ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820953&group_id=5470 From noreply at sourceforge.net Thu Oct 9 23:50:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 9 23:50:17 2003 Subject: [Python-bugs-list] [ python-Bugs-819510 ] httplib.SSLFile lacks readlines() method Message-ID: Bugs item #819510, was opened at 2003-10-07 14:32 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819510&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Campbell (mattcamp) Assigned to: Nobody/Anonymous (nobody) Summary: httplib.SSLFile lacks readlines() method Initial Comment: The httplib.SSLFile class has no readlines() method. A readlines() method is necessary if the SSL server sends back an HTTP/0.9 response, since in that case, the httplib.LineAndFileWrapper class is used. The_done () method in httplib.LineAndFileWrapper has this statement: self.readlines = self._file.readlines Which causes an error when "self._file" refers to SSLFile. This happens even if I only call the read() method on LineAndFileWrapper. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-09 22:50 Message: Logged In: YES user_id=139865 This is a duplicate of bug #792101. Patch #817854 may provide a fix but needs to be reviewed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819510&group_id=5470 From noreply at sourceforge.net Sat Oct 11 06:59:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 11 06:59:55 2003 Subject: [Python-bugs-list] [ python-Bugs-821701 ] reduce docs neglect a very important piece of information. Message-ID: Bugs item #821701, was opened at 2003-10-11 06: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=821701&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: reduce docs neglect a very important piece of information. Initial Comment: I was writing a platform-independent hash function for pathnames, and the documentation was useless for determining in which order the arguments to the reducing function are given. In the one example given, the arguments are of the same type, and the reducing function uses a commutative operator, so it doesn't matter. In my case, however, I was doing this: >>> reduce(lambda h, s: h ^ hash(s), s.split(os.path.sep), 0) -740391245 where the arguments aren't the same type, so order does matter. I actually tried this first (since it's the order of arguments of foldl in Haskell/SML): >>> reduce(lambda s, h: h ^ hash(s), s.split(os.path.sep), 0) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in TypeError: unsupported operand type(s) for ^: 'str' and 'int' Especially considering that the order of arguments here is counter to the traditional order of arguments for such functions in functional languages, I think there should be a note in the documentation about the order of arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470 From noreply at sourceforge.net Sat Oct 11 07:35:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 11 07:36:00 2003 Subject: [Python-bugs-list] [ python-Bugs-815999 ] ImportError: No module named _socket Message-ID: Bugs item #815999, was opened at 2003-10-01 13:21 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peter Stauffert (stauffert) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named _socket Initial Comment: Hi There is a problem during the installation of python 2.3.1: I used configure with the following options: ./configure --enable-shared=yes --with-signal- module=yes --with-cxx=/usr/freeware/bin/c++ make runs to the end, only warning messages are displayed. Running "make test" on a SGI Origin200, IRIX 6.5-18 I got the following error message: test test___all__ failed -- Traceback (most recent call last): File "/install/fw/Python-2.3.1/Lib/test/test___all__.py", line 54, in test_all import _socket ImportError: No module named _socket This looks like the python bug 565710 reported for python 2.2.1 which was solved by modifications of setup.py in the top level directory. But setup.py was modified in python 2.3.1 and I could not apply the old patch to the new version. Could you help me with this problem? Thanks a lot Peter Stauffert ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-11 07:35 Message: Logged In: YES user_id=99508 I have this same bug on Solaris 7 with 2.3.2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-03 20:24 Message: Logged In: YES user_id=29957 Does the patch available from www.python.org/bugs.html fix this problem? Which compiler did you use? From the configure line, above, it looks like you might be using gcc? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 09:28 Message: Logged In: YES user_id=21627 Can you please attach the build log? In particular, it would be importing to see whether building _socket was attempted, and failed. Maybe your compiler just doesn't work??? ---------------------------------------------------------------------- Comment By: casey dunn (caseyd) Date: 2003-10-01 15:53 Message: Logged In: YES user_id=878394 I have seen this on Solaris as well, recent and old vintages. Casey Dunn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 From noreply at sourceforge.net Sat Oct 11 12:10:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 11 12:10:46 2003 Subject: [Python-bugs-list] [ python-Bugs-821818 ] pyclbr.readmodule_ex() Message-ID: Bugs item #821818, was opened at 2003-10-11 20: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=821818&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: pyclbr.readmodule_ex() Initial Comment: Function readmodule_ex() from pyclbr module needs to be described. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821818&group_id=5470 From noreply at sourceforge.net Sat Oct 11 12:44:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 11 12:44:52 2003 Subject: [Python-bugs-list] [ python-Bugs-821701 ] reduce docs neglect a very important piece of information. Message-ID: Bugs item #821701, was opened at 2003-10-11 05:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470 Category: Documentation >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) >Assigned to: Raymond Hettinger (rhettinger) Summary: reduce docs neglect a very important piece of information. Initial Comment: I was writing a platform-independent hash function for pathnames, and the documentation was useless for determining in which order the arguments to the reducing function are given. In the one example given, the arguments are of the same type, and the reducing function uses a commutative operator, so it doesn't matter. In my case, however, I was doing this: >>> reduce(lambda h, s: h ^ hash(s), s.split(os.path.sep), 0) -740391245 where the arguments aren't the same type, so order does matter. I actually tried this first (since it's the order of arguments of foldl in Haskell/SML): >>> reduce(lambda s, h: h ^ hash(s), s.split(os.path.sep), 0) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in TypeError: unsupported operand type(s) for ^: 'str' and 'int' Especially considering that the order of arguments here is counter to the traditional order of arguments for such functions in functional languages, I think there should be a note in the documentation about the order of arguments. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-11 11:44 Message: Logged In: YES user_id=80475 I've bumped into this also and always solved it by experiment. I'll update the docs to clarity the situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470 From noreply at sourceforge.net Sat Oct 11 15:13:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 11 15:13:13 2003 Subject: [Python-bugs-list] [ python-Bugs-820397 ] __nonzero__() returns 1/0 Message-ID: Bugs item #820397, was opened at 2003-10-08 21:34 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820397&group_id=5470 Category: None Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: __nonzero__() returns 1/0 Initial Comment: This is similar to Patch [820195]. http://www.python.org/sf/820195 number.__nonzero__() returns 1/0, while number != 0 returns True/False. >>> n = 1 >>> n.__nonzero__() 1 >>> n != 0 True >>> n = 0 >>> n.__nonzero__() 0 >>> n != 0 False >>> c = 1+1j >>> c.__nonzero__() 1 >>> c != 0 True >>> c = 0j >>> c.__nonzero__() 0 >>> c != 0 False ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-11 14:13 Message: Logged In: YES user_id=80475 Fixed. See: Objects/typeobject.c 2.247 Thanks for the bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820397&group_id=5470 From noreply at sourceforge.net Sat Oct 11 15:49:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 11 15:49:23 2003 Subject: [Python-bugs-list] [ python-Bugs-821896 ] _set_cloexec of tempfile.py uses incorrect error handling Message-ID: Bugs item #821896, was opened at 2003-10-11 21:49 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=821896&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Per Cederqvist (ceder) Assigned to: Nobody/Anonymous (nobody) Summary: _set_cloexec of tempfile.py uses incorrect error handling Initial Comment: The _set_cloexec function of tempfile.py looks like this on Unix-like platforms: def _set_cloexec(fd): flags = _fcntl.fcntl(fd, _fcntl.F_GETFD, 0) if flags >= 0: # flags read successfully, modify flags |= _fcntl.FD_CLOEXEC _fcntl.fcntl(fd, _fcntl.F_SETFD, flags) However, fcntl.fcntl() will never return a negative value. If an error occurs, it will instead raise an exception: >>> fcntl.fcntl(10, fcntl.F_GETFD, 0) Traceback (most recent call last): File "", line 1, in ? IOError: [Errno 9] Bad file descriptor (This was tested on Linux.) I doubt that this will ever cause any problems, except if somebody uses the code as an example and copies the error to their own code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821896&group_id=5470 From noreply at sourceforge.net Sat Oct 11 18:08:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 11 18:09:02 2003 Subject: [Python-bugs-list] [ python-Bugs-821948 ] fcntl() not working on sparc (python 2.2.3) Message-ID: Bugs item #821948, was opened at 2003-10-11 19: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=821948&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Alberto Bertogli (albertogli) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl() not working on sparc (python 2.2.3) Initial Comment: In sparc, fcntl.fcntl() is not working properly under Python 2.2.3; a simple strace of: import fcntl, sys fcntl.fcntl(sys.stdin.fileno(), fcntl.F_SETFL, os.O_NONBLOCK) will reveal that on sparc there's no fcntl() syscall done, while under x86 it works as expected (ie. the syscall is there). I have not tested yet with Python 2.3 but I'll let you know when I do. Thanks, Alberto ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 From noreply at sourceforge.net Sat Oct 11 21:23:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 11 21:23:55 2003 Subject: [Python-bugs-list] [ python-Bugs-822005 ] Carbon.CarbonEvt.ReceiveNextEvent args wrong Message-ID: Bugs item #822005, was opened at 2003-10-12 14: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=822005&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gregory Ewing (gcewing) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.CarbonEvt.ReceiveNextEvent args wrong Initial Comment: In MacPython, the ReceiveNextEvent function in Carbon.CarbonEvt has been incorrectly wrapped. In C, the 2nd argument of ReceiveNextEvent is declared as an EventTypeSpec *. This has been wrapped as though it were a pointer to a single EventTypeSpec, but it's actually a pointer to an array of EventTypeSpecs. The first two arguments of ReceiveNextEvent should be represented in Python by a single argument containing a list of EventTypeSpecs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=822005&group_id=5470 From noreply at sourceforge.net Sun Oct 12 00:42:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 12 00:42:29 2003 Subject: [Python-bugs-list] [ python-Bugs-450225 ] urljoin fails RFC tests Message-ID: Bugs item #450225, was opened at 2001-08-11 22:10 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450225&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Aaron Swartz (aaronsw) Assigned to: Brett Cannon (bcannon) Summary: urljoin fails RFC tests Initial Comment: I've put together a test suite for Python's URLparse module, based on the tests in Appendix C of RFC2396 (the URI RFC). They're available at: http://lists.w3.org/Archives/Public/uri/2001Aug/ 0013.html The major problem seems to be that it treats queries and parameters as special components (not just normal parts of the path), making this related to: http://sourceforge.net/tracker/?group_id=5470& atid=105470&func=detail&aid=210834 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-10-11 21:42 Message: Logged In: YES user_id=357491 rev. 1.42 of Lib/urlparse.py and rev. 1.13 of Lib/test/ test_urlparse.py have mbrierst's fixes (thanks, Michael) after I had to do a second commit to get the comment correct. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-12 00:24 Message: Logged In: YES user_id=357491 Since there is the random possibility that this might break code that depends on this to act like RFC 1808 instead of 2396 and 2.3 has hit beta I am going to wait for 2.4 before I deal with this. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-11 17:35 Message: Logged In: YES user_id=357491 mbrierst is right. From C.1 of RFC 2396 (with http://a/b/c/d;p?q as the base): ?y = http://a/b/c/?y ;x = http://a/b/c/;x And notice how this contradicts RFC 1808 ( with as the base): ?y = ;x = So obviously there is a conflict here. And since RFC 2396 says "it revises and replaces the generic definitions in RFC 1738 and RFC 1808" (of which "generic" just means the actual syntax) this means that RFC 2396's solution should override. Now the issue is whether the patch for this is the right thing to do (I am ignoring if the patch is correct; have not tested it yet). This shouldn't break anything since the whole point of urlparse.urljoin is to have an abstracted way to create URIs without the user having to worry about all of these rules. So I say that it should be changed. Fred, do you mind if I reassign this patch to myself and deal with it? ---------------------------------------------------------------------- Comment By: Michael Stone (mbrierst) Date: 2003-02-03 13:02 Message: Logged In: YES user_id=670441 The two failing tests could not pass because RFC 1808 and RFC 2396 seem to conflict when a relative URI is given as just ;y or just ?y. RFC 2396 claims to update RFC 1808, so presumably it describes the correct behavior. The patch in this message (I can't upload it on sourceforge here for some reason) brings urljoin's behavior in line with RFC 2396, and changes the appropriate test cases. I think if you apply this patch this bug can be closed. Let me know what you think Index: python/dist/src/Lib/urlparse.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/urlparse.py,v retrieving revision 1.39 diff -c -r1.39 urlparse.py *** python/dist/src/Lib/urlparse.py 7 Jan 2003 02:09:16 -0000 1.39 --- python/dist/src/Lib/urlparse.py 3 Feb 2003 20:51:08 -0000 *************** *** 157,169 **** if path[:1] == '/': return urlunparse((scheme, netloc, path, params, query, fragment)) ! if not path: ! if not params: ! params = bparams ! if not query: ! query = bquery return urlunparse((scheme, netloc, bpath, ! params, query, fragment)) segments = bpath.split('/')[:-1] + path.split('/') # XXX The stuff below is bogus in various ways... if segments[-1] == '.': --- 157,165 ---- if path[:1] == '/': return urlunparse((scheme, netloc, path, params, query, fragment)) ! if not (path or params or query): return urlunparse((scheme, netloc, bpath, ! bparams, bquery, fragment)) segments = bpath.split('/')[:-1] + path.split('/') # XXX The stuff below is bogus in various ways... if segments[-1] == '.': Index: python/dist/src/Lib/test/test_urlparse.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Lib/test/test_urlparse.py,v retrieving revision 1.11 diff -c -r1.11 test_urlparse.py *** python/dist/src/Lib/test/test_urlparse.py 6 Jan 2003 20:27:03 -0000 1.11 --- python/dist/src/Lib/test/test_urlparse.py 3 Feb 2003 20:51:12 -0000 *************** *** 54,59 **** --- 54,63 ---- self.assertEqual(urlparse.urlunparse(urlparse.urlparse(u)), u) def test_RFC1808(self): + # updated by RFC 2396 + # self.checkJoin(RFC1808_BASE, '?y', 'http://a/b/c/d;p?y') + # self.checkJoin(RFC1808_BASE, ';x', 'http://a/b/c/d;x') + # "normal" cases from RFC 1808: self.checkJoin(RFC1808_BASE, 'g:h', 'g:h') self.checkJoin(RFC1808_BASE, 'g', 'http://a/b/c/g') *************** *** 61,74 **** self.checkJoin(RFC1808_BASE, 'g/', 'http://a/b/c/g/') self.checkJoin(RFC1808_BASE, '/g', 'http://a/g') self.checkJoin(RFC1808_BASE, '//g', 'http://g') - self.checkJoin(RFC1808_BASE, '?y', 'http://a/b/c/d;p?y') self.checkJoin(RFC1808_BASE, 'g?y', 'http://a/b/c/g?y') self.checkJoin(RFC1808_BASE, 'g?y/./x', 'http://a/b/c/g?y/./x') self.checkJoin(RFC1808_BASE, '#s', 'http://a/b/c/d;p?q#s') self.checkJoin(RFC1808_BASE, 'g#s', 'http://a/b/c/g#s') self.checkJoin(RFC1808_BASE, 'g#s/./x', 'http://a/b/c/g#s/./x') self.checkJoin(RFC1808_BASE, 'g?y#s', 'http://a/b/c/g?y#s') - self.checkJoin(RFC1808_BASE, ';x', 'http://a/b/c/d;x') self.checkJoin(RFC1808_BASE, 'g;x', 'http://a/b/c/g;x') self.checkJoin(RFC1808_BASE, 'g;x?y#s', 'http://a/b/c/g;x?y#s') self.checkJoin(RFC1808_BASE, '.', 'http://a/b/c/') --- 65,76 ---- *************** *** 103,111 **** def test_RFC2396(self): # cases from RFC 2396 ! ### urlparse.py as of v 1.32 fails on these two ! #self.checkJoin(RFC2396_BASE, '?y', 'http://a/b/c/?y') ! #self.checkJoin(RFC2396_BASE, ';x', 'http://a/b/c/;x') self.checkJoin(RFC2396_BASE, 'g:h', 'g:h') self.checkJoin(RFC2396_BASE, 'g', 'http://a/b/c/g') --- 105,113 ---- def test_RFC2396(self): # cases from RFC 2396 ! # conflict with RFC 1808, tests commented out there ! self.checkJoin(RFC2396_BASE, '?y', 'http://a/b/c/?y') ! self.checkJoin(RFC2396_BASE, ';x', 'http://a/b/c/;x') self.checkJoin(RFC2396_BASE, 'g:h', 'g:h') self.checkJoin(RFC2396_BASE, 'g', 'http://a/b/c/g') ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2002-03-22 21:34 Message: Logged In: YES user_id=44345 added Aaron's RFC 2396 tests to test_urlparse.py version 1.4 - the two failing tests are commented out ---------------------------------------------------------------------- Comment By: Jon Ribbens (jribbens) Date: 2002-03-18 06:22 Message: Logged In: YES user_id=76089 I think it would be better btw if '..' components taking you 'off the top' were stripped. RFC 2396 says this is valid behaviour, and it's what 'real' browsers do. i.e. http://a/b/ + ../../../d == http://a/d ---------------------------------------------------------------------- Comment By: Aaron Swartz (aaronsw) Date: 2001-11-05 10:34 Message: Logged In: YES user_id=122141 Oops, meant to attach it... ---------------------------------------------------------------------- Comment By: Aaron Swartz (aaronsw) Date: 2001-11-05 10:30 Message: Logged In: YES user_id=122141 Sure, here they are: import urlparse base = 'http://a/b/c/d;p?q' assert urlparse.urljoin(base, 'g:h') == 'g:h' assert urlparse.urljoin(base, 'g') == 'http://a/b/c/g' assert urlparse.urljoin(base, './g') == 'http://a/b/c/g' assert urlparse.urljoin(base, 'g/') == 'http://a/b/c/g/' assert urlparse.urljoin(base, '/g') == 'http://a/g' assert urlparse.urljoin(base, '//g') == 'http://g' assert urlparse.urljoin(base, '?y') == 'http://a/b/c/?y' assert urlparse.urljoin(base, 'g?y') == 'http://a/b/c/g?y' assert urlparse.urljoin(base, '#s') == 'http://a/b/c/ d;p?q#s' assert urlparse.urljoin(base, 'g#s') == 'http://a/b/c/g#s' assert urlparse.urljoin(base, 'g?y#s') == 'http://a/b/c/ g?y#s' assert urlparse.urljoin(base, ';x') == 'http://a/b/c/;x' assert urlparse.urljoin(base, 'g;x') == 'http://a/b/c/g;x' assert urlparse.urljoin(base, 'g;x?y#s') == 'http://a/b/c/ g;x?y#s' assert urlparse.urljoin(base, '.') == 'http://a/b/c/' assert urlparse.urljoin(base, './') == 'http://a/b/c/' assert urlparse.urljoin(base, '..') == 'http://a/b/' assert urlparse.urljoin(base, '../') == 'http://a/b/' assert urlparse.urljoin(base, '../g') == 'http://a/b/g' assert urlparse.urljoin(base, '../..') == 'http://a/' assert urlparse.urljoin(base, '../../') == 'http://a/' assert urlparse.urljoin(base, '../../g') == 'http://a/g' assert urlparse.urljoin(base, '') == base assert urlparse.urljoin(base, '../../../g') == 'http://a/../g' assert urlparse.urljoin(base, '../../../../g') == 'http://a/../../g' assert urlparse.urljoin(base, '/./g') == 'http://a/./g' assert urlparse.urljoin(base, '/../g') == 'http://a/../g' assert urlparse.urljoin(base, 'g.') == 'http://a/b/c/ g.' assert urlparse.urljoin(base, '.g') == 'http://a/b/c/ .g' assert urlparse.urljoin(base, 'g..') == 'http://a/b/c/ g..' assert urlparse.urljoin(base, '..g') == 'http://a/b/c/ ..g' assert urlparse.urljoin(base, './../g') == 'http://a/b/g' assert urlparse.urljoin(base, './g/.') == 'http://a/b/c/ g/' assert urlparse.urljoin(base, 'g/./h') == 'http://a/b/c/ g/h' assert urlparse.urljoin(base, 'g/../h') == 'http://a/b/c/ h' assert urlparse.urljoin(base, 'g;x=1/./y') == 'http://a/b/c/g;x=1/y' assert urlparse.urljoin(base, 'g;x=1/../y') == 'http://a/b/ c/y' assert urlparse.urljoin(base, 'g?y/./x') == 'http://a/b/c/g?y/./x' assert urlparse.urljoin(base, 'g?y/../x') == 'http://a/b/c/g?y/../x' assert urlparse.urljoin(base, 'g#s/./x') == 'http://a/b/ c/g#s/./x' assert urlparse.urljoin(base, 'g#s/../x') == 'http://a/b/ c/g#s/../x' ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-11-05 10:05 Message: Logged In: YES user_id=3066 This looks like its probably related to #478038; I'll try to tackle them together. Can you attach your tests to the bug report on SF? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=450225&group_id=5470 From noreply at sourceforge.net Sun Oct 12 00:49:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 12 00:49:37 2003 Subject: [Python-bugs-list] [ python-Bugs-726911 ] platform module needs docs (LaTeX) Message-ID: Bugs item #726911, was opened at 2003-04-24 07:22 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726911&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Brett Cannon (bcannon) Summary: platform module needs docs (LaTeX) Initial Comment: The platform module needs to be documented in the Library Reference. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-10-11 21:49 Message: Logged In: YES user_id=357491 Just to cross-reference, patch #785752 is someone's attempt at this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-04 19:45 Message: Logged In: YES user_id=3066 We have a volunteer! Just check it in when you're ready, Brett. I'll be glad to make any ancilliary updates if you're not able to test the LaTeX yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726911&group_id=5470 From noreply at sourceforge.net Sun Oct 12 03:42:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 12 03:42:59 2003 Subject: [Python-bugs-list] [ python-Bugs-820953 ] dbm Error Message-ID: Bugs item #820953, was opened at 2003-10-09 16:13 Message generated for change (Comment added) made by giffordj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820953&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim Gifford (giffordj) Assigned to: Nobody/Anonymous (nobody) Summary: dbm Error Initial Comment: Receive the following error during make install of python 2.3.2. Any suggestions or is it safe to ignore. building 'dbm' extension gcc -pthread -DNDEBUG -g -march=pentium2 -mmmx - O2 -pipe -Wall -Wstrict-prototypes -fPIC -fno-strict- aliasing -DHAVE_NDBM_H -I. -I/usr/src/Python- 2.3.2/./Include -I/usr/local/include -I/usr/src/Python- 2.3.2/Include -I/usr/src/Python-2.3.2 - c /usr/src/Python-2.3.2/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o gcc -pthread -shared build/temp.linux-i686- 2.3/dbmmodule.o -L/usr/local/lib -o build/lib.linux-i686- 2.3/dbm.so *** WARNING: renaming "dbm" since importing it failed: build/lib.linux-i686-2.3/dbm.so: undefined symbol: dbm_firstkey running build_scripts ---------------------------------------------------------------------- >Comment By: Jim Gifford (giffordj) Date: 2003-10-12 00:42 Message: Logged In: YES user_id=492775 Upon further research, when this error occurs installation does continue, but libpython2.3.a is never created. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820953&group_id=5470 From noreply at sourceforge.net Sun Oct 12 06:42:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 12 06:42:55 2003 Subject: [Python-bugs-list] [ python-Bugs-789995 ] access fails on Windows with Unicode file name Message-ID: Bugs item #789995, was opened at 2003-08-17 09:10 Message generated for change (Settings changed) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789995&group_id=5470 Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) >Assigned to: Martin v. L?wis (loewis) Summary: access fails on Windows with Unicode file name Initial Comment: Using current CVS version of Python 2.4 on Windows 2000. The os.access function fails when the filename argument is a Unicode string: File "test_pep277.py", line 103, in test_directory os.access(filename,os.R_OK) UnicodeEncodeError: 'ascii' codec can't encode character '\udf' in position 0: ordinal not in range(128) I will upload a patch to fix this in the patch manager. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789995&group_id=5470 From noreply at sourceforge.net Sun Oct 12 06:43:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 12 06:43:16 2003 Subject: [Python-bugs-list] [ python-Bugs-761267 ] Failure in comparing unicode string Message-ID: Bugs item #761267, was opened at 2003-06-26 18:02 Message generated for change (Settings changed) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761267&group_id=5470 Category: Unicode Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stephen Brown (skbrown1975) >Assigned to: Nobody/Anonymous (nobody) Summary: Failure in comparing unicode string Initial Comment: Received a SystemError: C:\Code\22 \Objects\longobject.c:231: bad argument to internal function The code was "if items[0] == self.InfoShareName:" where items is an array of strings and self.InfoShareName is a unicode string declared by self.InfoShareName = unicode(ShareName) ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-06-28 16:01 Message: Logged In: YES user_id=38388 I can't see how your code could possibly cause the error you indicate. Please provide an executable example with real data. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-27 05:01 Message: Logged In: YES user_id=33168 Can you attach a file which demonstrates this bug. I cannot reproduce it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=761267&group_id=5470 From noreply at sourceforge.net Sun Oct 12 13:07:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 12 13:07:16 2003 Subject: [Python-bugs-list] [ python-Bugs-822262 ] Typo in Doc/api/intro.tex Message-ID: Bugs item #822262, was opened at 2003-10-12 17: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=822262&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Florent Rougon (frougon) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in Doc/api/intro.tex Initial Comment: There is a typo in Doc/api/intro.tex, line 283 (from Python 2.3.2) : "the type of the type of the object" should be replaced by "the type of the object". Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=822262&group_id=5470 From noreply at sourceforge.net Sun Oct 12 13:38:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 12 13:38:47 2003 Subject: [Python-bugs-list] [ python-Bugs-810408 ] mkstemp doesn't return abspath Message-ID: Bugs item #810408, was opened at 2003-09-22 07:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810408&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: mkstemp doesn't return abspath Initial Comment: The document of tempfile.mkstemp says that, "mkstemp() returns a tuple containing an OS-level handle to an open file (as would be returned by os.open()) and the absolute pathname of that file, in that order." However, if you specify the directory a relative path, it doesn't return an absolute pathname. >>> import tempfile >>> tempfile.mkstemp() (5, '/tmp/tmpHBq8rz') >>> tempfile.mkstemp(dir='.') (3, './tmpvK7BEr') >>> tempfile.mkstemp(dir='./test') (4, './test/tmplB7GZF') ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-12 19:38 Message: Logged In: YES user_id=21627 Fixed with #810914. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-09-24 15:01 Message: Logged In: YES user_id=31511 As I have written the patch, my comment: I think the code should be fixed, because the filename is instantly usable if returned with an absolute path. If the patch is not accepted please consider to use at least the additional testcase which catches the bug. ---------------------------------------------------------------------- Comment By: George Yoshida (quiver) Date: 2003-09-23 13:34 Message: Logged In: YES user_id=671362 Michael has submitted a patch to return absolute pathname. http://www.python.org/sf/810914 fix for mkstemp with relative paths (bug #810408) His fix looks good to me. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-23 13:03 Message: Logged In: YES user_id=29957 Anyone got an opinion on this one? Should the docs be fixed, or the code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810408&group_id=5470 From noreply at sourceforge.net Sun Oct 12 13:41:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 12 13:42:08 2003 Subject: [Python-bugs-list] [ python-Bugs-821948 ] fcntl() not working on sparc (python 2.2.3) Message-ID: Bugs item #821948, was opened at 2003-10-12 00:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Alberto Bertogli (albertogli) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl() not working on sparc (python 2.2.3) Initial Comment: In sparc, fcntl.fcntl() is not working properly under Python 2.2.3; a simple strace of: import fcntl, sys fcntl.fcntl(sys.stdin.fileno(), fcntl.F_SETFL, os.O_NONBLOCK) will reveal that on sparc there's no fcntl() syscall done, while under x86 it works as expected (ie. the syscall is there). I have not tested yet with Python 2.3 but I'll let you know when I do. Thanks, Alberto ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-12 19:41 Message: Logged In: YES user_id=21627 I cannot reproduce this. My binary of 2.2.1 does read(3, "import fcntl, sys, os\nfcntl.fcnt"..., 8192) = 84 read(3, "", 8192) = 0 llseek(3, 0, SEEK_CUR) = 0 close(3) = 0 fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(24, 3), ...}) = 0 fcntl(0, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 sigaction(SIGINT, NULL, {0xff25ff24, ~[KILL STOP], 0}) = 0 sigaction(SIGINT, {SIG_DFL}, NULL) = 0 Can you attach your strace output? Can you also try truss? What Solaris version and patches, what compiler? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 From noreply at sourceforge.net Sun Oct 12 15:27:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 12 15:27:51 2003 Subject: [Python-bugs-list] [ python-Bugs-819860 ] PythonIDE interactive window Unicode bug Message-ID: Bugs item #819860, was opened at 2003-10-08 11:57 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819860&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jurjen N.E. Bos (jneb) Assigned to: Just van Rossum (jvr) Summary: PythonIDE interactive window Unicode bug Initial Comment: Platform: OS X 10.2.8 Python 2.3 final, running PythonIDE, but I guess the bug is also in 2.3.2. In the "Python Interactive" window (characters between acute brackets to be interpreted by humans): >>> print "" >>> print u"" That's not bad, because it cannot be printed in ASCII. Fine. But now, at every CR, the dialog opens again! The same problem when running code in an edit window; there you get in a state that any print command gives this error. I managed to fix it, but I am not so sure this is the right way to do it. I changed PyConsole.ConsoleTextWidget.flush: There are two lines (that are not together, but can safely be moved together) self.ted.WEInsert(stuff, None, None) self._buf = "" and I replaced this by try: self.ted.WEInsert(stuff, None, None) finally: self._buf = "" The same code occurs in PyConsole.PyOutput.flush(); this fixes the bug in the other case. - Jurjen ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-10-12 21:27 Message: Logged In: YES user_id=92689 Fixed in CVS. Thanks for the report! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-10-08 12:49 Message: Logged In: YES user_id=45365 Just, could you take a look at this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819860&group_id=5470 From noreply at sourceforge.net Sun Oct 12 18:10:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 12 18:10:40 2003 Subject: [Python-bugs-list] [ python-Bugs-821701 ] reduce docs neglect a very important piece of information. Message-ID: Bugs item #821701, was opened at 2003-10-11 06:59 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Raymond Hettinger (rhettinger) Summary: reduce docs neglect a very important piece of information. Initial Comment: I was writing a platform-independent hash function for pathnames, and the documentation was useless for determining in which order the arguments to the reducing function are given. In the one example given, the arguments are of the same type, and the reducing function uses a commutative operator, so it doesn't matter. In my case, however, I was doing this: >>> reduce(lambda h, s: h ^ hash(s), s.split(os.path.sep), 0) -740391245 where the arguments aren't the same type, so order does matter. I actually tried this first (since it's the order of arguments of foldl in Haskell/SML): >>> reduce(lambda s, h: h ^ hash(s), s.split(os.path.sep), 0) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in TypeError: unsupported operand type(s) for ^: 'str' and 'int' Especially considering that the order of arguments here is counter to the traditional order of arguments for such functions in functional languages, I think there should be a note in the documentation about the order of arguments. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-12 18:10 Message: Logged In: YES user_id=593130 A draft of clarification text: The rule is that the first (left) arg is the current cumulation and the second (right) is the update value from the sequence. The initial cumulation is either the optional initializer or the first item of the sequence, at least one of which most exist to avoid a TypeError. I inferred the left/right arg rule from ''' reduce(lambda x, y: x+y, [1, 2, 3, 4, 5]) calculates ((((1+2) +3)+4)+5). ''' but an explicit statement would be helpful. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-11 12:44 Message: Logged In: YES user_id=80475 I've bumped into this also and always solved it by experiment. I'll update the docs to clarity the situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470 From noreply at sourceforge.net Mon Oct 13 01:51:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 01:51:43 2003 Subject: [Python-bugs-list] [ python-Bugs-815999 ] ImportError: No module named _socket Message-ID: Bugs item #815999, was opened at 2003-10-02 03:21 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peter Stauffert (stauffert) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named _socket Initial Comment: Hi There is a problem during the installation of python 2.3.1: I used configure with the following options: ./configure --enable-shared=yes --with-signal- module=yes --with-cxx=/usr/freeware/bin/c++ make runs to the end, only warning messages are displayed. Running "make test" on a SGI Origin200, IRIX 6.5-18 I got the following error message: test test___all__ failed -- Traceback (most recent call last): File "/install/fw/Python-2.3.1/Lib/test/test___all__.py", line 54, in test_all import _socket ImportError: No module named _socket This looks like the python bug 565710 reported for python 2.2.1 which was solved by modifications of setup.py in the top level directory. But setup.py was modified in python 2.3.1 and I could not apply the old patch to the new version. Could you help me with this problem? Thanks a lot Peter Stauffert ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-13 15:51 Message: Logged In: YES user_id=29957 Works for me on Solaris 2.6, 7 and 8. What compiler, what version, what error did you get during the build of socketmodule? ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-11 21:35 Message: Logged In: YES user_id=99508 I have this same bug on Solaris 7 with 2.3.2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-04 10:24 Message: Logged In: YES user_id=29957 Does the patch available from www.python.org/bugs.html fix this problem? Which compiler did you use? From the configure line, above, it looks like you might be using gcc? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 23:28 Message: Logged In: YES user_id=21627 Can you please attach the build log? In particular, it would be importing to see whether building _socket was attempted, and failed. Maybe your compiler just doesn't work??? ---------------------------------------------------------------------- Comment By: casey dunn (caseyd) Date: 2003-10-02 05:53 Message: Logged In: YES user_id=878394 I have seen this on Solaris as well, recent and old vintages. Casey Dunn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 From noreply at sourceforge.net Mon Oct 13 03:59:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 03:59:52 2003 Subject: [Python-bugs-list] [ python-Bugs-820605 ] tkinter's 'after' and 'threads' on multiprocessor Message-ID: Bugs item #820605, was opened at 2003-10-09 05:15 Message generated for change (Comment added) made by drewp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820605&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Zoran Bosnjak (zoranbosnjak) Assigned to: Martin v. L?wis (loewis) Summary: tkinter's 'after' and 'threads' on multiprocessor Initial Comment: I have attached simple testfile which works fine on single processor machine, but it does not work on multiprocessor machine (dual XEON - HT 2x 2.4GHz, python 2.1.1 (or python 2.2), RedHat 9.0 distr., linux-kernel 2.4.20-20-9smp). At the moment I can not tell where the problem is. It could be - in python core, - in threading module - in tkinter, TCL, Tk - in linux kernel Problem description: - I use tkinter's (Tk's) after method for periodic calls - I also start a few dummy threads which have nothong to do with tkinter. - (see the attached file) - After a while, one or more threads stop running and 'after' method stops working (they simply block). The situation is different each time I run the script. The problem is random and probability raises with number of threads. Normaly the problem occours after a few seconds with 8 threads. I am willing to run additional tests if someone has any idea where to start debugging. regards, Zoran Bosnjak ---------------------------------------------------------------------- Comment By: Drew Perttula (drewp) Date: 2003-10-12 23:59 Message: Logged In: YES user_id=127598 The given test program works for me on a dual AMD 1400MHz with py2.2.2 and linux 2.4.19. By 'works', I mean that after 60sec, the program is still outputting spurts like this: 8 1066031758.16 5 1066031758.16 1 1066031758.16 7 1066031758.16 3 1066031758.16 6 1066031758.16 4 1066031758.16 2 1066031758.21 I am also available for running additional tests. My email is drewp at big asterisk .com less the spaces. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820605&group_id=5470 From noreply at sourceforge.net Mon Oct 13 07:20:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 07:20:59 2003 Subject: [Python-bugs-list] [ python-Bugs-822668 ] tarfile exception on large .tar files Message-ID: Bugs item #822668, was opened at 2003-10-13 13:20 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=822668&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Johan Fredrik ?hman (johanfo) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile exception on large .tar files Initial Comment: The following exception is thrown when I write a lot of data > 10Gb directly to my tapestreamer. Is this normal? Traceback (most recent call last): File "/usr/local/metroField/fieldPlugins/Backup.py", line 184, in run self._doBackup() File "/usr/local/metroField/fieldPlugins/Backup.py", line 333, in _doBackup arc.close() File "/usr/local/metroField/fieldPlugins/Backup.py", line 533, in close self.tf.close() File "/usr/local/lib/python2.3/tarfile.py", line 1009, in close self.fileobj.close() File "/usr/local/lib/python2.3/tarfile.py", line 360, in close self.fileobj.write(struct.pack(" Bugs item #815999, was opened at 2003-10-01 13:21 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peter Stauffert (stauffert) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named _socket Initial Comment: Hi There is a problem during the installation of python 2.3.1: I used configure with the following options: ./configure --enable-shared=yes --with-signal- module=yes --with-cxx=/usr/freeware/bin/c++ make runs to the end, only warning messages are displayed. Running "make test" on a SGI Origin200, IRIX 6.5-18 I got the following error message: test test___all__ failed -- Traceback (most recent call last): File "/install/fw/Python-2.3.1/Lib/test/test___all__.py", line 54, in test_all import _socket ImportError: No module named _socket This looks like the python bug 565710 reported for python 2.2.1 which was solved by modifications of setup.py in the top level directory. But setup.py was modified in python 2.3.1 and I could not apply the old patch to the new version. Could you help me with this problem? Thanks a lot Peter Stauffert ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-13 10:33 Message: Logged In: YES user_id=99508 If you don't mind, I'll just link you to my comp.lang.python post about it: http://groups.google.com/groups?q=group:comp.lang.python+solaris+7&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=698f09f8.0310100915.359b2e09%40posting.google.com&rnum=9 That has the exact compilation error. I've tried passing the --disable-IPV6 option to configure (as MvL mentioned) and it seemed to compile, but I still don't have access to the _socket library, probably due to the second error I mentioned. I tried the fix in the bug #565710 (adding runtime_library_dirs to setup.py) but to no avail. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-13 01:51 Message: Logged In: YES user_id=29957 Works for me on Solaris 2.6, 7 and 8. What compiler, what version, what error did you get during the build of socketmodule? ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-11 07:35 Message: Logged In: YES user_id=99508 I have this same bug on Solaris 7 with 2.3.2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-03 20:24 Message: Logged In: YES user_id=29957 Does the patch available from www.python.org/bugs.html fix this problem? Which compiler did you use? From the configure line, above, it looks like you might be using gcc? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 09:28 Message: Logged In: YES user_id=21627 Can you please attach the build log? In particular, it would be importing to see whether building _socket was attempted, and failed. Maybe your compiler just doesn't work??? ---------------------------------------------------------------------- Comment By: casey dunn (caseyd) Date: 2003-10-01 15:53 Message: Logged In: YES user_id=878394 I have seen this on Solaris as well, recent and old vintages. Casey Dunn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 From noreply at sourceforge.net Mon Oct 13 10:35:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 10:35:56 2003 Subject: [Python-bugs-list] [ python-Bugs-821701 ] reduce docs neglect a very important piece of information. Message-ID: Bugs item #821701, was opened at 2003-10-11 06:59 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Raymond Hettinger (rhettinger) Summary: reduce docs neglect a very important piece of information. Initial Comment: I was writing a platform-independent hash function for pathnames, and the documentation was useless for determining in which order the arguments to the reducing function are given. In the one example given, the arguments are of the same type, and the reducing function uses a commutative operator, so it doesn't matter. In my case, however, I was doing this: >>> reduce(lambda h, s: h ^ hash(s), s.split(os.path.sep), 0) -740391245 where the arguments aren't the same type, so order does matter. I actually tried this first (since it's the order of arguments of foldl in Haskell/SML): >>> reduce(lambda s, h: h ^ hash(s), s.split(os.path.sep), 0) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in TypeError: unsupported operand type(s) for ^: 'str' and 'int' Especially considering that the order of arguments here is counter to the traditional order of arguments for such functions in functional languages, I think there should be a note in the documentation about the order of arguments. ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-13 10:35 Message: Logged In: YES user_id=99508 I'd call the argument an "accumulator" rather than a "cumulation." The last sentence has a small typo, "at least one of which most exist" instead of "at least one of which must exist." ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-12 18:10 Message: Logged In: YES user_id=593130 A draft of clarification text: The rule is that the first (left) arg is the current cumulation and the second (right) is the update value from the sequence. The initial cumulation is either the optional initializer or the first item of the sequence, at least one of which most exist to avoid a TypeError. I inferred the left/right arg rule from ''' reduce(lambda x, y: x+y, [1, 2, 3, 4, 5]) calculates ((((1+2) +3)+4)+5). ''' but an explicit statement would be helpful. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-11 12:44 Message: Logged In: YES user_id=80475 I've bumped into this also and always solved it by experiment. I'll update the docs to clarity the situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470 From noreply at sourceforge.net Mon Oct 13 11:31:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 11:32:41 2003 Subject: [Python-bugs-list] [ python-Bugs-821701 ] reduce docs neglect a very important piece of information. Message-ID: Bugs item #821701, was opened at 2003-10-11 06:59 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Raymond Hettinger (rhettinger) Summary: reduce docs neglect a very important piece of information. Initial Comment: I was writing a platform-independent hash function for pathnames, and the documentation was useless for determining in which order the arguments to the reducing function are given. In the one example given, the arguments are of the same type, and the reducing function uses a commutative operator, so it doesn't matter. In my case, however, I was doing this: >>> reduce(lambda h, s: h ^ hash(s), s.split(os.path.sep), 0) -740391245 where the arguments aren't the same type, so order does matter. I actually tried this first (since it's the order of arguments of foldl in Haskell/SML): >>> reduce(lambda s, h: h ^ hash(s), s.split(os.path.sep), 0) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in TypeError: unsupported operand type(s) for ^: 'str' and 'int' Especially considering that the order of arguments here is counter to the traditional order of arguments for such functions in functional languages, I think there should be a note in the documentation about the order of arguments. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-13 11:31 Message: Logged In: YES user_id=593130 Revised clarification text to possibly add after current first sentence. The first (left) argument is the accumulator; the second (right) is the update value from the sequence. The accumulator starts as the initializer, if given, or as seq[0]. An empty sequence with no initializer is a TypeError. Follow this with the example. I think the current wordier sentence about initialization could be deleted (or greatly reduced if above does not encompass all of current content). ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-13 10:35 Message: Logged In: YES user_id=99508 I'd call the argument an "accumulator" rather than a "cumulation." The last sentence has a small typo, "at least one of which most exist" instead of "at least one of which must exist." ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-12 18:10 Message: Logged In: YES user_id=593130 A draft of clarification text: The rule is that the first (left) arg is the current cumulation and the second (right) is the update value from the sequence. The initial cumulation is either the optional initializer or the first item of the sequence, at least one of which most exist to avoid a TypeError. I inferred the left/right arg rule from ''' reduce(lambda x, y: x+y, [1, 2, 3, 4, 5]) calculates ((((1+2) +3)+4)+5). ''' but an explicit statement would be helpful. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-11 12:44 Message: Logged In: YES user_id=80475 I've bumped into this also and always solved it by experiment. I'll update the docs to clarity the situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470 From noreply at sourceforge.net Mon Oct 13 11:45:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 11:46:05 2003 Subject: [Python-bugs-list] [ python-Bugs-794140 ] cygwin builds do not embed Message-ID: Bugs item #794140, was opened at 2003-08-24 07:18 Message generated for change (Comment added) made by jlt63 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794140&group_id=5470 Category: Build Group: Python 2.4 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Alejandro Lopez-Valencia (dradul) Assigned to: Jason Tishler (jlt63) Summary: cygwin builds do not embed Initial Comment: As an example case, try to build a copy of vim with an embeded python interpreter: """ indow.o objects/if_python.o objects/py_config.o objects/netbeans.o object s/version.o -lncurses -liconv -lintl - L/usr/lib/python2.3/config -lpyt hon2.3 -lutil -lm objects/py_config.o(.data+0x4):config.c: referencia a `_initthread' sin definir objects/py_config.o(.data+0xc):config.c: referencia a `_initsignal' sin definir objects/py_config.o(.data+0x14):config.c: referencia a `_initposix' sin definir objects/py_config.o(.data+0x1c):config.c: referencia a `_initerrno' sin definir objects/py_config.o(.data+0x24):config.c: referencia a `_init_sre' sin definir objects/py_config.o(.data+0x2c):config.c: referencia a `_init_codecs' sin defini r """ As you can see, it doesn't embed. I have tracked down the failure to a problem in the LDSHARED defaults provided by configure.in. The default supplied is: LDSHARED="gcc -shared -Wl,--enable-auto-image- base";; but this *does not* work. As per Cygwin documentation on the creation of DLLs, this works (already tested compiling vim under the same conditions): LDSHARED="gcc -shared -Wl,--enable-auto-image-base - Wl,--export-all-symbols -Wl,--enable-auto-import";; As a side note, please notice that this problem, proper user of GNU ld flags under win32, has a direct impact on the possible success of a true Mingw32 port (which I expect eagerly). ---------------------------------------------------------------------- >Comment By: Jason Tishler (jlt63) Date: 2003-10-13 07:45 Message: Logged In: YES user_id=86216 The Cygwin python-2.3.2-1 package has this patch already applied: http://cygwin.com/ml/cygwin-announce/2003- 10/msg00010.html ---------------------------------------------------------------------- Comment By: John Sumsion (jdsumsion) Date: 2003-09-22 11:07 Message: Logged In: YES user_id=867854 I'm a newbie at building O/S software, but at least I figured this one out (running Cygwin 1.5.5-1 on XP Pro). Thanks to Jason who provided the embed2 patch and helped me understand this more fully. Running on cygwin, if you get the python package (2.3-2), follow these steps to get an updated libpython2.3.dll.a (and .dll): cd /usr/src/python-2.3-2 patch -p0 < embed2.diff (attached to this issue, don't use embed.diff or pyport.h.diff) ./configure make make install (only if you want to install these files) Now look in the current directory for the .dll.a and the .dll. I was able to build vim 6.2.98 (src also from cygwin dist) with an embedded python interpreter with the resulting files (I copied the .dll.a to /usr/lib/python2.3/config and the .dll to /usr/bin). ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-09-04 04:01 Message: Logged In: YES user_id=86216 > python import vim; vim.current.line = vim.current.line.upper () The above example works fine with embed2.diff applied. I tested (builing Python) under Red Hat Linux 8.0 too. Commited as: Include/pyport.h 2.63 Modules/gcmodule.c 2.72 Python/import.c 2.223 Python/marshal.c 1.75 ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-09-04 03:51 Message: Logged In: YES user_id=86216 I should have mentioned that the patch assumes Python's builtin modules are only written in C (not C++). If this assumption is incorrect, then I will add the standard __cplusplus/extern "C" idiom. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-09-04 03:37 Message: Logged In: YES user_id=86216 Combined the original two patches into one and refreshed against current CVS. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-09-02 12:11 Message: Logged In: YES user_id=86216 Please try again with the second patch applied too. The combination of them seem to work for me. > I have tested it against the release23-maint CVS branch, >and unfortunately it doesn't work.. BTW, it would have been helpful it you indicated that the first patch eliminated all but 3 link errors. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-27 07:31 Message: Logged In: YES user_id=86216 What do you get when you execute the following? $ objdump -p libpython2.3.dll | fgrep '] init' Are you building vim against the newly built Python? ---------------------------------------------------------------------- Comment By: Alejandro Lopez-Valencia (dradul) Date: 2003-08-27 07:13 Message: Logged In: YES user_id=659006 I have tested it against the release23-maint CVS branch, and unfortunately it doesn't work.. *Sigh* I mentioned the autotools because I didn't see the patch at first (the wonders of top posting, who designed this bug-tracker?). But now... I think we need an export symbols definition file... :-( ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-27 06:12 Message: Logged In: YES user_id=86216 > Yes, I am willing to test it. Thanks. Are you willing to build against Python CVS? Or, do you need me to provide you with replacements for libpython2.3.dll.a and libpython2.3.dll? > Yet... Don't you think you are complicating the issue, the > autotool files and your life, too much? I don't think so. Note that my approach does not affect any autotools files. > There are no obvious security issues involved and... IIRC, exporting all symbols under Win32 can cause multiple definition link errors. > Anyway, it's your ballgame, it's your call. I appreciate your willingness to acquiesce. ---------------------------------------------------------------------- Comment By: Alejandro Lopez-Valencia (dradul) Date: 2003-08-27 05:06 Message: Logged In: YES user_id=659006 Yes, I am willing to test it. Yet... Don't you think you are complicating the issue, the autotool files and your life, too much? There are no obvious security issues involved and the procedure only adds extra text to the DATA segment in the DLLs, there are no changes in the actual object code; it won't become a hybrid DLL/implib such as cygwin1.dll! Take any Unix shared library (Linux, Solaris, BSD, whatever), and it is already exporting *all symbols*, how else would you be able to link to them? There are no import libs, that's a Windows/MacOS Classic abomination as far as I am concerned :-) Anyway, it's your ballgame, it's your call. Cheers ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-26 05:46 Message: Logged In: YES user_id=86216 I would prefer to just export the missing symbols than all of them which is unnecessary and possibly problematic. The attached patch (against Python CVS) exports the following additionally symbols: $ objdump -p libpython2.3.dll | fgrep '] init' [ 794] init_codecs [ 795] init_sre [ 796] init_symtable [ 797] initerrno [ 798] initposix [ 799] initsignal [ 800] initthread [ 801] initxxsubtype [ 802] initzipimport Does the above meet your needs? Are you willing to test your vim build against it? ---------------------------------------------------------------------- Comment By: Alejandro Lopez-Valencia (dradul) Date: 2003-08-26 03:05 Message: Logged In: YES user_id=659006 Opps! Sorry, my link fell down in the middle of submitting the form. ---------------------------------------------------------------------- Comment By: Alejandro Lopez-Valencia (dradul) Date: 2003-08-26 03:00 Message: Logged In: YES user_id=659006 Ramifications to changing LDSHARED? I don't perceive any besides having slightly bigger dlls, and the possibility to extract symbol definitions and create import libraries out of plugins, perhaps even linking extensoins directly (as in writing derivative extensions from, say, Numeric). Adding -Wl,--enable-auto-import doesn't modify the defaults but hushes the linker, less perturbing line noise in stderr. On giving you an example, I only use python under cygwin and having just managed to build my first embedded vim, I'm starting to experiment. There are some reasonable examples in vim's documentation (see ':h if_pyth.txt'). This works for me: 1. Type a line of text. Leave cursor on line. 2. Enter command mode and type: python import vim; vim.current.line = vim.current.line.upper () And about your "Huh?", this is the python bug tracker last time I checked. The issue is a GNU ld/Win32 issue, not necessarily exclusive to Cygwin. I am leaving a hint for future developers. Cheers. ---------------------------------------------------------------------- Comment By: Alejandro Lopez-Valencia (dradul) Date: 2003-08-26 02:57 Message: Logged In: YES user_id=659006 Ramifications to changing LDSHARED? I don't perceive any besides having slightly bigger dlls, and the possibility to extract symbol definitions and create import libraries out of plugins, perhaps even linking extensoins directly (as in writing derivative extensions from, say, Numeric). Adding -Wl,--enable-auto-import doesn't modify the defaults but hushes the linker, less perturbing line noise in stderr. On giving you an example, I only use python under cygwin and having just managed to build my first embedded vim, I'm starting to experiment. There are some reasonable examples in vim's documentation (see ':h if_pyth.txt'). This works for me: 1. Type a line of text. Leave cursor on line. 2. Enter command mode and type: python import vim; vim.current.line = vim.current.line.upper () And about your "Huh?", this is the python bug tracker last time I checked. The issue is a GNU ld/Win32 issue, not necessarily exclusive to Cygwin. I am leaving a hint for future developers. Cheers. ---------------------------------------------------------------------- Comment By: Jason Tishler (jlt63) Date: 2003-08-25 10:32 Message: Logged In: YES user_id=86216 AFAICT, changing LDSHARED will affect building extensions too. So, I am very hesitant to change its definition without fully understanding the ramifications. Note that Cygwin Python extensions have been working for almost three years now. Additionally, I WAG that there are many more people building extensions than embedding. > LDSHARED="gcc -shared -Wl,--enable-auto-image-base > -Wl,--export-all-symbols -Wl,--enable-auto-import";; I can understand why adding "-Wl,--export-all-symbols" fixes the above link errors. However, I don't understand why "-Wl,--enable-auto-import" would help. IIRC, it defaults to enabled anyway. Does vim with an embeded python interpreter build without this option? Can you provide me a small embedded example so I can do some testing? Using vim seems a bit unwieldy. > As a side note, please notice that this problem, proper > user of GNU ld flags under win32, has a direct impact on > the possible success of a true Mingw32 port (which I > expect eagerly). Huh? How is this related to the report Cygwin problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=794140&group_id=5470 From noreply at sourceforge.net Mon Oct 13 13:06:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 13:06:52 2003 Subject: [Python-bugs-list] [ python-Bugs-821948 ] fcntl() not working on sparc (python 2.2.3) Message-ID: Bugs item #821948, was opened at 2003-10-11 19:08 Message generated for change (Comment added) made by albertogli You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Alberto Bertogli (albertogli) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl() not working on sparc (python 2.2.3) Initial Comment: In sparc, fcntl.fcntl() is not working properly under Python 2.2.3; a simple strace of: import fcntl, sys fcntl.fcntl(sys.stdin.fileno(), fcntl.F_SETFL, os.O_NONBLOCK) will reveal that on sparc there's no fcntl() syscall done, while under x86 it works as expected (ie. the syscall is there). I have not tested yet with Python 2.3 but I'll let you know when I do. Thanks, Alberto ---------------------------------------------------------------------- >Comment By: Alberto Bertogli (albertogli) Date: 2003-10-13 14:06 Message: Logged In: YES user_id=44390 I'm sorry I didn't specify earlier, this is a box running Linux (gentoo distribution) with: Linux Kernel 2.4.20 glibc 2.2.5 gcc 2.95.3 python 2.2.3 The fragment of the strace output is the following, it's between I press the final '\n' and the response '0\n' appears: write(1, "\n", 1) = 1 rt_sigprocmask(SIG_BLOCK, [INT], [32], 8) = 0 ioctl(0, 0x8024540a, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [32], NULL, 8) = 0 rt_sigaction(SIGINT, {0x700486f8, [], 0}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGALRM, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTSTP, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTTOU, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTTIN, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGWINCH, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGINT, NULL, {0x700486f8, [], 0}, 0, 8) = 0 rt_sigaction(SIGINT, {0x700486f8, [], 0}, NULL, 0x701431c8, 8) = 0 nfssvc(0) = 0 write(1, "0\n", 2) = 2 On x86 the fcntl64() syscall happens right before the write(). I don't think the bug is present in earlier versions of Python because I remember this used to work fine before the upgrade, however I can't pinpoint the exact release this started to show up. Let me know if you need additional info or want me to do some tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-12 14:41 Message: Logged In: YES user_id=21627 I cannot reproduce this. My binary of 2.2.1 does read(3, "import fcntl, sys, os\nfcntl.fcnt"..., 8192) = 84 read(3, "", 8192) = 0 llseek(3, 0, SEEK_CUR) = 0 close(3) = 0 fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(24, 3), ...}) = 0 fcntl(0, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 sigaction(SIGINT, NULL, {0xff25ff24, ~[KILL STOP], 0}) = 0 sigaction(SIGINT, {SIG_DFL}, NULL) = 0 Can you attach your strace output? Can you also try truss? What Solaris version and patches, what compiler? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 From noreply at sourceforge.net Mon Oct 13 13:48:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 13:48:38 2003 Subject: [Python-bugs-list] [ python-Bugs-822262 ] Typo in Doc/api/intro.tex Message-ID: Bugs item #822262, was opened at 2003-10-12 13:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=822262&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Florent Rougon (frougon) >Assigned to: Neal Norwitz (nnorwitz) Summary: Typo in Doc/api/intro.tex Initial Comment: There is a typo in Doc/api/intro.tex, line 283 (from Python 2.3.2) : "the type of the type of the object" should be replaced by "the type of the object". Thanks. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-13 13:48 Message: Logged In: YES user_id=33168 Thanks! Checked in as: intro.tex 1.4 and 1.3.24.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=822262&group_id=5470 From noreply at sourceforge.net Mon Oct 13 13:55:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 13:55:53 2003 Subject: [Python-bugs-list] [ python-Bugs-821701 ] reduce docs neglect a very important piece of information. Message-ID: Bugs item #821701, was opened at 2003-10-11 05:59 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Raymond Hettinger (rhettinger) Summary: reduce docs neglect a very important piece of information. Initial Comment: I was writing a platform-independent hash function for pathnames, and the documentation was useless for determining in which order the arguments to the reducing function are given. In the one example given, the arguments are of the same type, and the reducing function uses a commutative operator, so it doesn't matter. In my case, however, I was doing this: >>> reduce(lambda h, s: h ^ hash(s), s.split(os.path.sep), 0) -740391245 where the arguments aren't the same type, so order does matter. I actually tried this first (since it's the order of arguments of foldl in Haskell/SML): >>> reduce(lambda s, h: h ^ hash(s), s.split(os.path.sep), 0) Traceback (most recent call last): File "", line 1, in ? File "", line 1, in TypeError: unsupported operand type(s) for ^: 'str' and 'int' Especially considering that the order of arguments here is counter to the traditional order of arguments for such functions in functional languages, I think there should be a note in the documentation about the order of arguments. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-13 12:55 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libfuncs.tex 1.150 and 1.143.8.6 ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-13 10:31 Message: Logged In: YES user_id=593130 Revised clarification text to possibly add after current first sentence. The first (left) argument is the accumulator; the second (right) is the update value from the sequence. The accumulator starts as the initializer, if given, or as seq[0]. An empty sequence with no initializer is a TypeError. Follow this with the example. I think the current wordier sentence about initialization could be deleted (or greatly reduced if above does not encompass all of current content). ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-13 09:35 Message: Logged In: YES user_id=99508 I'd call the argument an "accumulator" rather than a "cumulation." The last sentence has a small typo, "at least one of which most exist" instead of "at least one of which must exist." ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-12 17:10 Message: Logged In: YES user_id=593130 A draft of clarification text: The rule is that the first (left) arg is the current cumulation and the second (right) is the update value from the sequence. The initial cumulation is either the optional initializer or the first item of the sequence, at least one of which most exist to avoid a TypeError. I inferred the left/right arg rule from ''' reduce(lambda x, y: x+y, [1, 2, 3, 4, 5]) calculates ((((1+2) +3)+4)+5). ''' but an explicit statement would be helpful. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-11 11:44 Message: Logged In: YES user_id=80475 I've bumped into this also and always solved it by experiment. I'll update the docs to clarity the situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821701&group_id=5470 From noreply at sourceforge.net Mon Oct 13 15:21:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 15:21:32 2003 Subject: [Python-bugs-list] [ python-Bugs-822974 ] Telnet.read_until() timeout parameter misleading Message-ID: Bugs item #822974, was opened at 2003-10-13 15: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=822974&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mitchel Quinn (mnquinn) Assigned to: Nobody/Anonymous (nobody) Summary: Telnet.read_until() timeout parameter misleading Initial Comment: Telnet.read_until(str,timeout) documentation reads as follows: Read until a given string, expected, is encountered or until timeout seconds have passed. When no match is found, return whatever is available instead, possibly the empty string. Raise EOFError if the connection is closed and no cooked data is available. However, the method does not behave in this manner. The method will only return if the call to select() on the socket is blocked for longer than the specified timeout. If there is a steady stream of data available, and it does not contain the specified string, this method will _NEVER_ return. A possible solution would be to subtract the elapsed time from the given timeout each time through the while loop. Here's a snippet of the code from telnetlib.py read_until(): if timeout is not None: s_args = s_args + (timeout,) while not self.eof and apply(select.select, s_args) == s_reply: i = max(0, len(self.cookedq)-n) self.fill_rawq() self.process_rawq() i = self.cookedq.find(match, i) if i >= 0: i = i+n buf = self.cookedq[:i] self.cookedq = self.cookedq[i:] return buf return self.read_very_lazy() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=822974&group_id=5470 From noreply at sourceforge.net Mon Oct 13 15:28:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 15:28:56 2003 Subject: [Python-bugs-list] [ python-Bugs-820605 ] tkinter's 'after' and 'threads' on multiprocessor Message-ID: Bugs item #820605, was opened at 2003-10-09 05:15 Message generated for change (Comment added) made by drewp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820605&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Zoran Bosnjak (zoranbosnjak) Assigned to: Martin v. L?wis (loewis) Summary: tkinter's 'after' and 'threads' on multiprocessor Initial Comment: I have attached simple testfile which works fine on single processor machine, but it does not work on multiprocessor machine (dual XEON - HT 2x 2.4GHz, python 2.1.1 (or python 2.2), RedHat 9.0 distr., linux-kernel 2.4.20-20-9smp). At the moment I can not tell where the problem is. It could be - in python core, - in threading module - in tkinter, TCL, Tk - in linux kernel Problem description: - I use tkinter's (Tk's) after method for periodic calls - I also start a few dummy threads which have nothong to do with tkinter. - (see the attached file) - After a while, one or more threads stop running and 'after' method stops working (they simply block). The situation is different each time I run the script. The problem is random and probability raises with number of threads. Normaly the problem occours after a few seconds with 8 threads. I am willing to run additional tests if someone has any idea where to start debugging. regards, Zoran Bosnjak ---------------------------------------------------------------------- Comment By: Drew Perttula (drewp) Date: 2003-10-13 11:28 Message: Logged In: YES user_id=127598 I forgot to show the after loop's output, which appears in random positions among the other threads' output. The more complete version of the output I see looks like this: 3 1066073253.53 1066073253.53 1066073253.53 7 4 1066073253.53 5 1066073253.53 1 1066073253.53 6 1066073253.53 2 1066073253.58 8 1066073253.85 1066073254.03 1 1066073254.03 2 1066073254.03 5 1066073254.03 So, no bug confirmation yet. ---------------------------------------------------------------------- Comment By: Drew Perttula (drewp) Date: 2003-10-12 23:59 Message: Logged In: YES user_id=127598 The given test program works for me on a dual AMD 1400MHz with py2.2.2 and linux 2.4.19. By 'works', I mean that after 60sec, the program is still outputting spurts like this: 8 1066031758.16 5 1066031758.16 1 1066031758.16 7 1066031758.16 3 1066031758.16 6 1066031758.16 4 1066031758.16 2 1066031758.21 I am also available for running additional tests. My email is drewp at big asterisk .com less the spaces. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820605&group_id=5470 From noreply at sourceforge.net Mon Oct 13 15:25:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 15:30:03 2003 Subject: [Python-bugs-list] [ python-Bugs-822974 ] Telnet.read_until() timeout parameter misleading Message-ID: Bugs item #822974, was opened at 2003-10-13 15:21 Message generated for change (Settings changed) made by mnquinn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=822974&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Mitchel Quinn (mnquinn) Assigned to: Nobody/Anonymous (nobody) Summary: Telnet.read_until() timeout parameter misleading Initial Comment: Telnet.read_until(str,timeout) documentation reads as follows: Read until a given string, expected, is encountered or until timeout seconds have passed. When no match is found, return whatever is available instead, possibly the empty string. Raise EOFError if the connection is closed and no cooked data is available. However, the method does not behave in this manner. The method will only return if the call to select() on the socket is blocked for longer than the specified timeout. If there is a steady stream of data available, and it does not contain the specified string, this method will _NEVER_ return. A possible solution would be to subtract the elapsed time from the given timeout each time through the while loop. Here's a snippet of the code from telnetlib.py read_until(): if timeout is not None: s_args = s_args + (timeout,) while not self.eof and apply(select.select, s_args) == s_reply: i = max(0, len(self.cookedq)-n) self.fill_rawq() self.process_rawq() i = self.cookedq.find(match, i) if i >= 0: i = i+n buf = self.cookedq[:i] self.cookedq = self.cookedq[i:] return buf return self.read_very_lazy() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=822974&group_id=5470 From noreply at sourceforge.net Mon Oct 13 17:27:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 17:27:18 2003 Subject: [Python-bugs-list] [ python-Bugs-815999 ] ImportError: No module named _socket Message-ID: Bugs item #815999, was opened at 2003-10-01 19:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peter Stauffert (stauffert) Assigned to: Nobody/Anonymous (nobody) Summary: ImportError: No module named _socket Initial Comment: Hi There is a problem during the installation of python 2.3.1: I used configure with the following options: ./configure --enable-shared=yes --with-signal- module=yes --with-cxx=/usr/freeware/bin/c++ make runs to the end, only warning messages are displayed. Running "make test" on a SGI Origin200, IRIX 6.5-18 I got the following error message: test test___all__ failed -- Traceback (most recent call last): File "/install/fw/Python-2.3.1/Lib/test/test___all__.py", line 54, in test_all import _socket ImportError: No module named _socket This looks like the python bug 565710 reported for python 2.2.1 which was solved by modifications of setup.py in the top level directory. But setup.py was modified in python 2.3.1 and I could not apply the old patch to the new version. Could you help me with this problem? Thanks a lot Peter Stauffert ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-13 23:27 Message: Logged In: YES user_id=21627 jemfinch, I very much doubt that you have the same problem as the submitter of this report, and your Usenet message gives hardly enough detail to analyse the problem; for example, the linker error you report has a truncated error message. Please submit a separate report, and report precisely what you did, the complete output that you got, and what exactly isn't working the way you expect it to work. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-13 16:33 Message: Logged In: YES user_id=99508 If you don't mind, I'll just link you to my comp.lang.python post about it: http://groups.google.com/groups?q=group:comp.lang.python+solaris+7&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=698f09f8.0310100915.359b2e09%40posting.google.com&rnum=9 That has the exact compilation error. I've tried passing the --disable-IPV6 option to configure (as MvL mentioned) and it seemed to compile, but I still don't have access to the _socket library, probably due to the second error I mentioned. I tried the fix in the bug #565710 (adding runtime_library_dirs to setup.py) but to no avail. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-13 07:51 Message: Logged In: YES user_id=29957 Works for me on Solaris 2.6, 7 and 8. What compiler, what version, what error did you get during the build of socketmodule? ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-11 13:35 Message: Logged In: YES user_id=99508 I have this same bug on Solaris 7 with 2.3.2. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-04 02:24 Message: Logged In: YES user_id=29957 Does the patch available from www.python.org/bugs.html fix this problem? Which compiler did you use? From the configure line, above, it looks like you might be using gcc? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-03 15:28 Message: Logged In: YES user_id=21627 Can you please attach the build log? In particular, it would be importing to see whether building _socket was attempted, and failed. Maybe your compiler just doesn't work??? ---------------------------------------------------------------------- Comment By: casey dunn (caseyd) Date: 2003-10-01 21:53 Message: Logged In: YES user_id=878394 I have seen this on Solaris as well, recent and old vintages. Casey Dunn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=815999&group_id=5470 From noreply at sourceforge.net Mon Oct 13 17:33:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 17:33:53 2003 Subject: [Python-bugs-list] [ python-Bugs-821948 ] fcntl() not working on sparc (python 2.2.3) Message-ID: Bugs item #821948, was opened at 2003-10-12 00:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Alberto Bertogli (albertogli) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl() not working on sparc (python 2.2.3) Initial Comment: In sparc, fcntl.fcntl() is not working properly under Python 2.2.3; a simple strace of: import fcntl, sys fcntl.fcntl(sys.stdin.fileno(), fcntl.F_SETFL, os.O_NONBLOCK) will reveal that on sparc there's no fcntl() syscall done, while under x86 it works as expected (ie. the syscall is there). I have not tested yet with Python 2.3 but I'll let you know when I do. Thanks, Alberto ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-13 23:33 Message: Logged In: YES user_id=21627 It would be good if you could attach preprocessor output and assembler code (both obtained through --save-temps) for fcntlmodule.c. If this is too large to attach you might need to compress it, if it is then still too large, you would need to strip all but fcntl_fcntl. Also, are you using a 32-bit or a 64-bit compiler? ---------------------------------------------------------------------- Comment By: Alberto Bertogli (albertogli) Date: 2003-10-13 19:06 Message: Logged In: YES user_id=44390 I'm sorry I didn't specify earlier, this is a box running Linux (gentoo distribution) with: Linux Kernel 2.4.20 glibc 2.2.5 gcc 2.95.3 python 2.2.3 The fragment of the strace output is the following, it's between I press the final '\n' and the response '0\n' appears: write(1, "\n", 1) = 1 rt_sigprocmask(SIG_BLOCK, [INT], [32], 8) = 0 ioctl(0, 0x8024540a, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [32], NULL, 8) = 0 rt_sigaction(SIGINT, {0x700486f8, [], 0}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGALRM, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTSTP, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTTOU, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTTIN, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGWINCH, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGINT, NULL, {0x700486f8, [], 0}, 0, 8) = 0 rt_sigaction(SIGINT, {0x700486f8, [], 0}, NULL, 0x701431c8, 8) = 0 nfssvc(0) = 0 write(1, "0\n", 2) = 2 On x86 the fcntl64() syscall happens right before the write(). I don't think the bug is present in earlier versions of Python because I remember this used to work fine before the upgrade, however I can't pinpoint the exact release this started to show up. Let me know if you need additional info or want me to do some tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-12 19:41 Message: Logged In: YES user_id=21627 I cannot reproduce this. My binary of 2.2.1 does read(3, "import fcntl, sys, os\nfcntl.fcnt"..., 8192) = 84 read(3, "", 8192) = 0 llseek(3, 0, SEEK_CUR) = 0 close(3) = 0 fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(24, 3), ...}) = 0 fcntl(0, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 sigaction(SIGINT, NULL, {0xff25ff24, ~[KILL STOP], 0}) = 0 sigaction(SIGINT, {SIG_DFL}, NULL) = 0 Can you attach your strace output? Can you also try truss? What Solaris version and patches, what compiler? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 From noreply at sourceforge.net Mon Oct 13 23:31:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 13 23:31:23 2003 Subject: [Python-bugs-list] [ python-Bugs-821948 ] fcntl() not working on sparc (python 2.2.3) Message-ID: Bugs item #821948, was opened at 2003-10-11 19:08 Message generated for change (Comment added) made by albertogli You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Alberto Bertogli (albertogli) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl() not working on sparc (python 2.2.3) Initial Comment: In sparc, fcntl.fcntl() is not working properly under Python 2.2.3; a simple strace of: import fcntl, sys fcntl.fcntl(sys.stdin.fileno(), fcntl.F_SETFL, os.O_NONBLOCK) will reveal that on sparc there's no fcntl() syscall done, while under x86 it works as expected (ie. the syscall is there). I have not tested yet with Python 2.3 but I'll let you know when I do. Thanks, Alberto ---------------------------------------------------------------------- >Comment By: Alberto Bertogli (albertogli) Date: 2003-10-14 00:31 Message: Logged In: YES user_id=44390 I'm attaching both, tar.bz2 compressed, about 45k, without any stripping whatsoever. Linux on Sparc userspace is always 32 bit, but the kernel is 64 bit on sparc64 and 32 bit on sparc32. In this case, userspace is 32 bit and kernel 64 bit. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-13 18:33 Message: Logged In: YES user_id=21627 It would be good if you could attach preprocessor output and assembler code (both obtained through --save-temps) for fcntlmodule.c. If this is too large to attach you might need to compress it, if it is then still too large, you would need to strip all but fcntl_fcntl. Also, are you using a 32-bit or a 64-bit compiler? ---------------------------------------------------------------------- Comment By: Alberto Bertogli (albertogli) Date: 2003-10-13 14:06 Message: Logged In: YES user_id=44390 I'm sorry I didn't specify earlier, this is a box running Linux (gentoo distribution) with: Linux Kernel 2.4.20 glibc 2.2.5 gcc 2.95.3 python 2.2.3 The fragment of the strace output is the following, it's between I press the final '\n' and the response '0\n' appears: write(1, "\n", 1) = 1 rt_sigprocmask(SIG_BLOCK, [INT], [32], 8) = 0 ioctl(0, 0x8024540a, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [32], NULL, 8) = 0 rt_sigaction(SIGINT, {0x700486f8, [], 0}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGALRM, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTSTP, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTTOU, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTTIN, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGWINCH, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGINT, NULL, {0x700486f8, [], 0}, 0, 8) = 0 rt_sigaction(SIGINT, {0x700486f8, [], 0}, NULL, 0x701431c8, 8) = 0 nfssvc(0) = 0 write(1, "0\n", 2) = 2 On x86 the fcntl64() syscall happens right before the write(). I don't think the bug is present in earlier versions of Python because I remember this used to work fine before the upgrade, however I can't pinpoint the exact release this started to show up. Let me know if you need additional info or want me to do some tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-12 14:41 Message: Logged In: YES user_id=21627 I cannot reproduce this. My binary of 2.2.1 does read(3, "import fcntl, sys, os\nfcntl.fcnt"..., 8192) = 84 read(3, "", 8192) = 0 llseek(3, 0, SEEK_CUR) = 0 close(3) = 0 fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(24, 3), ...}) = 0 fcntl(0, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 sigaction(SIGINT, NULL, {0xff25ff24, ~[KILL STOP], 0}) = 0 sigaction(SIGINT, {SIG_DFL}, NULL) = 0 Can you attach your strace output? Can you also try truss? What Solaris version and patches, what compiler? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 From noreply at sourceforge.net Tue Oct 14 00:23:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 00:24:00 2003 Subject: [Python-bugs-list] [ python-Bugs-823209 ] cmath.log doesn't have the same interface as math.log. Message-ID: Bugs item #823209, was opened at 2003-10-14 00: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=823209&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: cmath.log doesn't have the same interface as math.log. Initial Comment: Somewhere along the way, math.log gained an optional "base" argument. cmath.log is still missing it. >>> print math.log.__doc__ log(x[, base]) -> the logarithm of x to the given base. If the base not specified, returns the natural logarithm (base e) of x. >>> print cmath.log.__doc__ log(x) Return the natural logarithm of x. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823209&group_id=5470 From noreply at sourceforge.net Tue Oct 14 03:08:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 03:08:47 2003 Subject: [Python-bugs-list] [ python-Bugs-706585 ] Expose FinderInfo in FSCatalogInfo Message-ID: Bugs item #706585, was opened at 2003-03-20 10:49 Message generated for change (Comment added) made by gcewing You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706585&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Expose FinderInfo in FSCatalogInfo Initial Comment: Carbon.File.FSCatalogInfo should expose the finder info (which is somehow defined as an anonymous short array in the header) as the correct Python object. Here's a comment by Mark Day: Yup, use the finderInfo. It's really either FileInfo or FolderInfo (both from Finder.h), depending on whether the object is a file or folder. Similarly, extFinderInfo is really either ExtendedFileInfo or ExtendedFolderInfo. I think there was some circular header dependency that prevented Files.h from using the Finder types explicitly. ---------------------------------------------------------------------- Comment By: Gregory Ewing (gcewing) Date: 2003-10-14 20:08 Message: Logged In: YES user_id=747684 Here's a patch for _Filemodule.c which exposes the finderInfo. It assumes it's always a FileInfo, which is not exactly right -- you may want to do things a bit more carefully. Also, someone with more knowledge of bgen than me will have to figure out what should really be patched and how. --- _Filemodule.c.orig Tue Oct 14 19:04:56 2003 +++ _Filemodule.c Sun Sep 21 13:41:04 2003 @@ -1,5 +1,10 @@ +/* + * This is a hacked version of _Filemodule.c from the Python 2.3 + * distribution to support access to the finderInfo field of the + * FSCatalogInfo data structure. + */ /* ========================== Module _File ========================== */ #include "Python.h" @@ -101,10 +106,23 @@ return Py_BuildValue("u#", itself->unicode, itself->length); } static PyObject *File_Error; +/* ----------------------- Object type FInfo declarations ------------------------ */ + +static PyTypeObject FInfo_Type; + +#define FInfo_Check(x) ((x)->ob_type == &FInfo_Type || PyObject_TypeCheck((x), &FInfo_Type)) + +typedef struct FInfoObject { + PyObject_HEAD + FInfo ob_itself; +} FInfoObject; + +static PyObject *FInfo_New(FInfo *itself); + /* ------------------- Object type FSCatalogInfo -------------------- */ static PyTypeObject FSCatalogInfo_Type; #define FSCatalogInfo_Check(x) ((x)->ob_type == &FSCatalogInfo_Type || PyObject_TypeCheck((x), &FSCatalogInfo_Type)) @@ -329,10 +347,25 @@ { return PyArg_Parse(v, "b", &self->ob_itself.userPrivileges)-1; return 0; } +static PyObject *FSCatalogInfo_get_finderInfo(FSCatalogInfoObject *self, void *closure) +{ + return FInfo_New((FInfo *)self->ob_itself.finderInfo); +} + +static int FSCatalogInfo_set_finderInfo(FSCatalogInfoObject *self, PyObject *v, void *closure) +{ + if (!FInfo_Check(v)) { + PyErr_SetString(PyExc_TypeError, "Expected an FInfo object"); + return -1; + } + *(FInfo *)self->ob_itself.finderInfo = ((FInfoObject *)v)->ob_itself; + return 0; +} + static PyGetSetDef FSCatalogInfo_getsetlist[] = { {"nodeFlags", (getter)FSCatalogInfo_get_nodeFlags, (setter)FSCatalogInfo_set_nodeFlags, NULL}, {"volume", (getter)FSCatalogInfo_get_volume, (setter)FSCatalogInfo_set_volume, NULL}, {"parentDirID", (getter)FSCatalogInfo_get_parentDirID, (setter)FSCatalogInfo_set_parentDirID, NULL}, {"nodeID", (getter)FSCatalogInfo_get_nodeID, (setter)FSCatalogInfo_set_nodeID, NULL}, @@ -347,10 +380,11 @@ {"dataPhysicalSize", (getter)FSCatalogInfo_get_dataPhysicalSize, (setter)FSCatalogInfo_set_dataPhysicalSize, NULL}, {"rsrcLogicalSize", (getter)FSCatalogInfo_get_rsrcLogicalSize, (setter)FSCatalogInfo_set_rsrcLogicalSize, NULL}, {"rsrcPhysicalSize", (getter)FSCatalogInfo_get_rsrcPhysicalSize, (setter)FSCatalogInfo_set_rsrcPhysicalSize, NULL}, {"sharingFlags", (getter)FSCatalogInfo_get_sharingFlags, (setter)FSCatalogInfo_set_sharingFlags, NULL}, {"userPrivileges", (getter)FSCatalogInfo_get_userPrivileges, (setter)FSCatalogInfo_set_userPrivileges, NULL}, + {"finderInfo", (getter)FSCatalogInfo_get_finderInfo, (setter)FSCatalogInfo_set_finderInfo, NULL}, {NULL, NULL, NULL, NULL}, }; #define FSCatalogInfo_compare NULL @@ -460,20 +494,11 @@ }; /* ----------------- End object type FSCatalogInfo ------------------ */ -/* ----------------------- Object type FInfo ------------------------ */ - -static PyTypeObject FInfo_Type; - -#define FInfo_Check(x) ((x)->ob_type == &FInfo_Type || PyObject_TypeCheck((x), &FInfo_Type)) - -typedef struct FInfoObject { - PyObject_HEAD - FInfo ob_itself; -} FInfoObject; +/* ----------------------- Object type FInfo implementation ------------------------ */ static PyObject *FInfo_New(FInfo *itself) { FInfoObject *it; if (itself == NULL) return PyMac_Error(resNotFound); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706585&group_id=5470 From noreply at sourceforge.net Tue Oct 14 06:03:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 06:03:36 2003 Subject: [Python-bugs-list] [ python-Bugs-823328 ] urllib2 digest auth is broken Message-ID: Bugs item #823328, was opened at 2003-10-14 20: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=823328&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 digest auth is broken Initial Comment: The urllib2 digest auth support is busted. For starters, it's looking for a header 'Authorization' with the auth header in it - the correct header is WWW-Authenticate, according to rfc2617 (and confirmed by the "what does apache do?" test). Even after making this fix, auth is still failing, not sure why yet. I'm not convinced, looking at the code, that it could have _ever_ worked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 From noreply at sourceforge.net Tue Oct 14 06:04:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 06:04:22 2003 Subject: [Python-bugs-list] [ python-Bugs-821948 ] fcntl() not working on sparc/linux (python 2.2.3) Message-ID: Bugs item #821948, was opened at 2003-10-12 08:08 Message generated for change (Settings changed) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Alberto Bertogli (albertogli) Assigned to: Nobody/Anonymous (nobody) >Summary: fcntl() not working on sparc/linux (python 2.2.3) Initial Comment: In sparc, fcntl.fcntl() is not working properly under Python 2.2.3; a simple strace of: import fcntl, sys fcntl.fcntl(sys.stdin.fileno(), fcntl.F_SETFL, os.O_NONBLOCK) will reveal that on sparc there's no fcntl() syscall done, while under x86 it works as expected (ie. the syscall is there). I have not tested yet with Python 2.3 but I'll let you know when I do. Thanks, Alberto ---------------------------------------------------------------------- Comment By: Alberto Bertogli (albertogli) Date: 2003-10-14 13:31 Message: Logged In: YES user_id=44390 I'm attaching both, tar.bz2 compressed, about 45k, without any stripping whatsoever. Linux on Sparc userspace is always 32 bit, but the kernel is 64 bit on sparc64 and 32 bit on sparc32. In this case, userspace is 32 bit and kernel 64 bit. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-14 07:33 Message: Logged In: YES user_id=21627 It would be good if you could attach preprocessor output and assembler code (both obtained through --save-temps) for fcntlmodule.c. If this is too large to attach you might need to compress it, if it is then still too large, you would need to strip all but fcntl_fcntl. Also, are you using a 32-bit or a 64-bit compiler? ---------------------------------------------------------------------- Comment By: Alberto Bertogli (albertogli) Date: 2003-10-14 03:06 Message: Logged In: YES user_id=44390 I'm sorry I didn't specify earlier, this is a box running Linux (gentoo distribution) with: Linux Kernel 2.4.20 glibc 2.2.5 gcc 2.95.3 python 2.2.3 The fragment of the strace output is the following, it's between I press the final '\n' and the response '0\n' appears: write(1, "\n", 1) = 1 rt_sigprocmask(SIG_BLOCK, [INT], [32], 8) = 0 ioctl(0, 0x8024540a, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [32], NULL, 8) = 0 rt_sigaction(SIGINT, {0x700486f8, [], 0}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGALRM, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTSTP, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTTOU, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTTIN, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGWINCH, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGINT, NULL, {0x700486f8, [], 0}, 0, 8) = 0 rt_sigaction(SIGINT, {0x700486f8, [], 0}, NULL, 0x701431c8, 8) = 0 nfssvc(0) = 0 write(1, "0\n", 2) = 2 On x86 the fcntl64() syscall happens right before the write(). I don't think the bug is present in earlier versions of Python because I remember this used to work fine before the upgrade, however I can't pinpoint the exact release this started to show up. Let me know if you need additional info or want me to do some tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-13 03:41 Message: Logged In: YES user_id=21627 I cannot reproduce this. My binary of 2.2.1 does read(3, "import fcntl, sys, os\nfcntl.fcnt"..., 8192) = 84 read(3, "", 8192) = 0 llseek(3, 0, SEEK_CUR) = 0 close(3) = 0 fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(24, 3), ...}) = 0 fcntl(0, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 sigaction(SIGINT, NULL, {0xff25ff24, ~[KILL STOP], 0}) = 0 sigaction(SIGINT, {SIG_DFL}, NULL) = 0 Can you attach your strace output? Can you also try truss? What Solaris version and patches, what compiler? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 From noreply at sourceforge.net Tue Oct 14 06:07:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 06:07:51 2003 Subject: [Python-bugs-list] [ python-Bugs-706585 ] Expose FinderInfo in FSCatalogInfo Message-ID: Bugs item #706585, was opened at 2003-03-19 23:49 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706585&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Expose FinderInfo in FSCatalogInfo Initial Comment: Carbon.File.FSCatalogInfo should expose the finder info (which is somehow defined as an anonymous short array in the header) as the correct Python object. Here's a comment by Mark Day: Yup, use the finderInfo. It's really either FileInfo or FolderInfo (both from Finder.h), depending on whether the object is a file or folder. Similarly, extFinderInfo is really either ExtendedFileInfo or ExtendedFolderInfo. I think there was some circular header dependency that prevented Files.h from using the Finder types explicitly. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-10-14 12:07 Message: Logged In: YES user_id=45365 Greg, could you attach the patch, in stead of having it inline? An inline patch is very difficult to get out of SF unscathed... ---------------------------------------------------------------------- Comment By: Gregory Ewing (gcewing) Date: 2003-10-14 09:08 Message: Logged In: YES user_id=747684 Here's a patch for _Filemodule.c which exposes the finderInfo. It assumes it's always a FileInfo, which is not exactly right -- you may want to do things a bit more carefully. Also, someone with more knowledge of bgen than me will have to figure out what should really be patched and how. --- _Filemodule.c.orig Tue Oct 14 19:04:56 2003 +++ _Filemodule.c Sun Sep 21 13:41:04 2003 @@ -1,5 +1,10 @@ +/* + * This is a hacked version of _Filemodule.c from the Python 2.3 + * distribution to support access to the finderInfo field of the + * FSCatalogInfo data structure. + */ /* ========================== Module _File ========================== */ #include "Python.h" @@ -101,10 +106,23 @@ return Py_BuildValue("u#", itself->unicode, itself->length); } static PyObject *File_Error; +/* ----------------------- Object type FInfo declarations ------------------------ */ + +static PyTypeObject FInfo_Type; + +#define FInfo_Check(x) ((x)->ob_type == &FInfo_Type || PyObject_TypeCheck((x), &FInfo_Type)) + +typedef struct FInfoObject { + PyObject_HEAD + FInfo ob_itself; +} FInfoObject; + +static PyObject *FInfo_New(FInfo *itself); + /* ------------------- Object type FSCatalogInfo -------------------- */ static PyTypeObject FSCatalogInfo_Type; #define FSCatalogInfo_Check(x) ((x)->ob_type == &FSCatalogInfo_Type || PyObject_TypeCheck((x), &FSCatalogInfo_Type)) @@ -329,10 +347,25 @@ { return PyArg_Parse(v, "b", &self->ob_itself.userPrivileges)-1; return 0; } +static PyObject *FSCatalogInfo_get_finderInfo(FSCatalogInfoObject *self, void *closure) +{ + return FInfo_New((FInfo *)self->ob_itself.finderInfo); +} + +static int FSCatalogInfo_set_finderInfo(FSCatalogInfoObject *self, PyObject *v, void *closure) +{ + if (!FInfo_Check(v)) { + PyErr_SetString(PyExc_TypeError, "Expected an FInfo object"); + return -1; + } + *(FInfo *)self->ob_itself.finderInfo = ((FInfoObject *)v)->ob_itself; + return 0; +} + static PyGetSetDef FSCatalogInfo_getsetlist[] = { {"nodeFlags", (getter)FSCatalogInfo_get_nodeFlags, (setter)FSCatalogInfo_set_nodeFlags, NULL}, {"volume", (getter)FSCatalogInfo_get_volume, (setter)FSCatalogInfo_set_volume, NULL}, {"parentDirID", (getter)FSCatalogInfo_get_parentDirID, (setter)FSCatalogInfo_set_parentDirID, NULL}, {"nodeID", (getter)FSCatalogInfo_get_nodeID, (setter)FSCatalogInfo_set_nodeID, NULL}, @@ -347,10 +380,11 @@ {"dataPhysicalSize", (getter)FSCatalogInfo_get_dataPhysicalSize, (setter)FSCatalogInfo_set_dataPhysicalSize, NULL}, {"rsrcLogicalSize", (getter)FSCatalogInfo_get_rsrcLogicalSize, (setter)FSCatalogInfo_set_rsrcLogicalSize, NULL}, {"rsrcPhysicalSize", (getter)FSCatalogInfo_get_rsrcPhysicalSize, (setter)FSCatalogInfo_set_rsrcPhysicalSize, NULL}, {"sharingFlags", (getter)FSCatalogInfo_get_sharingFlags, (setter)FSCatalogInfo_set_sharingFlags, NULL}, {"userPrivileges", (getter)FSCatalogInfo_get_userPrivileges, (setter)FSCatalogInfo_set_userPrivileges, NULL}, + {"finderInfo", (getter)FSCatalogInfo_get_finderInfo, (setter)FSCatalogInfo_set_finderInfo, NULL}, {NULL, NULL, NULL, NULL}, }; #define FSCatalogInfo_compare NULL @@ -460,20 +494,11 @@ }; /* ----------------- End object type FSCatalogInfo ------------------ */ -/* ----------------------- Object type FInfo ------------------------ */ - -static PyTypeObject FInfo_Type; - -#define FInfo_Check(x) ((x)->ob_type == &FInfo_Type || PyObject_TypeCheck((x), &FInfo_Type)) - -typedef struct FInfoObject { - PyObject_HEAD - FInfo ob_itself; -} FInfoObject; +/* ----------------------- Object type FInfo implementation ------------------------ */ static PyObject *FInfo_New(FInfo *itself) { FInfoObject *it; if (itself == NULL) return PyMac_Error(resNotFound); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706585&group_id=5470 From noreply at sourceforge.net Tue Oct 14 06:12:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 06:12:15 2003 Subject: [Python-bugs-list] [ python-Bugs-823328 ] urllib2 digest auth is broken Message-ID: Bugs item #823328, was opened at 2003-10-14 20:03 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 digest auth is broken Initial Comment: The urllib2 digest auth support is busted. For starters, it's looking for a header 'Authorization' with the auth header in it - the correct header is WWW-Authenticate, according to rfc2617 (and confirmed by the "what does apache do?" test). Even after making this fix, auth is still failing, not sure why yet. I'm not convinced, looking at the code, that it could have _ever_ worked. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 20:12 Message: Logged In: YES user_id=29957 Hm. Looking through comments, it's possible that this used to work with an older, broken, apache digest mode. It certainly fails with 2.0.47... :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 From noreply at sourceforge.net Tue Oct 14 08:00:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 08:00:46 2003 Subject: [Python-bugs-list] [ python-Bugs-823380 ] distutils: dir[ectory]_created Message-ID: Bugs item #823380, was opened at 2003-10-14 14: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=823380&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lukasz Pankowski (lupan) Assigned to: Nobody/Anonymous (nobody) Summary: distutils: dir[ectory]_created Initial Comment: In docutils documentation in section `The Postinstallation script' (python/dist/src/Doc/dist/dist.tex) mensions function dir_created, while it should be directory_created (python/dist/src/PC/bdist_wininst/install.c). Grepping the CVS tree shows the inconsistency: lupan@psi:[~/local/python]$ find -type f -print0 | xargs -0 grep [ry]_created ./dist/src/Doc/dist/dist.tex:dir_created(pathname) ./dist/src/PC/bdist_wininst/install.c: {"directory_created", DirectoryCreated, METH_VARARGS, NULL}, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823380&group_id=5470 From noreply at sourceforge.net Tue Oct 14 08:16:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 08:17:01 2003 Subject: [Python-bugs-list] [ python-Bugs-823328 ] urllib2 digest auth is broken Message-ID: Bugs item #823328, was opened at 2003-10-14 20:03 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: urllib2 digest auth is broken Initial Comment: The urllib2 digest auth support is busted. For starters, it's looking for a header 'Authorization' with the auth header in it - the correct header is WWW-Authenticate, according to rfc2617 (and confirmed by the "what does apache do?" test). Even after making this fix, auth is still failing, not sure why yet. I'm not convinced, looking at the code, that it could have _ever_ worked. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 22:16 Message: Logged In: YES user_id=29957 Ok, we're not handling the qop=auth style of Digest, as specified in the RFC. I'm working on it now. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 20:12 Message: Logged In: YES user_id=29957 Hm. Looking through comments, it's possible that this used to work with an older, broken, apache digest mode. It certainly fails with 2.0.47... :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 From noreply at sourceforge.net Tue Oct 14 08:37:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 08:37:13 2003 Subject: [Python-bugs-list] [ python-Bugs-823405 ] Problems with msvcirt.dll in Windows 98 SE Message-ID: Bugs item #823405, was opened at 2003-10-14 10: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=823405&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Cleber Akira Nakandakare (cakira) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with msvcirt.dll in Windows 98 SE Initial Comment: Hi! After I installed Python 2.3.2 in my Windows 98 SE (Version 4.10.2222 A), I've got problems with the library msvcirt.dll (or msvcrt.dll, whatever). The problem is exactly described in http://support.microsoft.com/?kbid=296551 Uninstalling Python did not resolve the problem, so I copied a spare msvcirt.dll (and only this file) to c:\windows\system and it looks everything works now. If you have any questions, send me an e-mail at cnakanda_at_fee.unicamp.br. Akira ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823405&group_id=5470 From noreply at sourceforge.net Tue Oct 14 09:18:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 09:18:49 2003 Subject: [Python-bugs-list] [ python-Bugs-823328 ] urllib2 digest auth is broken Message-ID: Bugs item #823328, was opened at 2003-10-14 20:03 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: urllib2 digest auth is broken Initial Comment: The urllib2 digest auth support is busted. For starters, it's looking for a header 'Authorization' with the auth header in it - the correct header is WWW-Authenticate, according to rfc2617 (and confirmed by the "what does apache do?" test). Even after making this fix, auth is still failing, not sure why yet. I'm not convinced, looking at the code, that it could have _ever_ worked. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 23:18 Message: Logged In: YES user_id=29957 The following patch gives us a urllib2 that supports digest auth again. I've tested against Apache-2..0.47, if someone wants to suggest another webserver to check with, please let me know. We now support RFC2617-compliant versions of digest auth. I have no idea what the code that was in there was trying to do, but it was broken all over the place - there is no way it would have worked. Note the following limitations: - We are sending a client nonce, but we're not checking the Authentication-Info that's coming back. - qop="auth-int" support is shaky. But apache looks like it doesn't support it properly, anyway. And it's no shakier than it was - algorithm="MD5-sess" isn't properly supported, but then, it wasn't before, either. - the code now has a limit of 5 failures in a row before it bails out . there was no limit previously, so it would recurse until the recursion limit was hit. I can't test the old code, unfortunately, but I _believe_ I've made it work again. It certainly could not have worked as it was. I've also not tested proxy-digest-auth - suggestions for a proxy server to try? Assuming my reading of the RFC is right, it should "just work". ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 22:16 Message: Logged In: YES user_id=29957 Ok, we're not handling the qop=auth style of Digest, as specified in the RFC. I'm working on it now. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 20:12 Message: Logged In: YES user_id=29957 Hm. Looking through comments, it's possible that this used to work with an older, broken, apache digest mode. It certainly fails with 2.0.47... :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 From noreply at sourceforge.net Tue Oct 14 09:29:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 09:29:52 2003 Subject: [Python-bugs-list] [ python-Bugs-820605 ] tkinter's 'after' and 'threads' on multiprocessor Message-ID: Bugs item #820605, was opened at 2003-10-09 15:15 Message generated for change (Comment added) made by zoranbosnjak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820605&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Zoran Bosnjak (zoranbosnjak) Assigned to: Martin v. L?wis (loewis) Summary: tkinter's 'after' and 'threads' on multiprocessor Initial Comment: I have attached simple testfile which works fine on single processor machine, but it does not work on multiprocessor machine (dual XEON - HT 2x 2.4GHz, python 2.1.1 (or python 2.2), RedHat 9.0 distr., linux-kernel 2.4.20-20-9smp). At the moment I can not tell where the problem is. It could be - in python core, - in threading module - in tkinter, TCL, Tk - in linux kernel Problem description: - I use tkinter's (Tk's) after method for periodic calls - I also start a few dummy threads which have nothong to do with tkinter. - (see the attached file) - After a while, one or more threads stop running and 'after' method stops working (they simply block). The situation is different each time I run the script. The problem is random and probability raises with number of threads. Normaly the problem occours after a few seconds with 8 threads. I am willing to run additional tests if someone has any idea where to start debugging. regards, Zoran Bosnjak ---------------------------------------------------------------------- >Comment By: Zoran Bosnjak (zoranbosnjak) Date: 2003-10-14 15:29 Message: Logged In: YES user_id=583469 I couldn't reproduce this bug under python2.3.2 any more (with the same testprogram). ---------------------------------------------------------------------- Comment By: Drew Perttula (drewp) Date: 2003-10-13 21:28 Message: Logged In: YES user_id=127598 I forgot to show the after loop's output, which appears in random positions among the other threads' output. The more complete version of the output I see looks like this: 3 1066073253.53 1066073253.53 1066073253.53 7 4 1066073253.53 5 1066073253.53 1 1066073253.53 6 1066073253.53 2 1066073253.58 8 1066073253.85 1066073254.03 1 1066073254.03 2 1066073254.03 5 1066073254.03 So, no bug confirmation yet. ---------------------------------------------------------------------- Comment By: Drew Perttula (drewp) Date: 2003-10-13 09:59 Message: Logged In: YES user_id=127598 The given test program works for me on a dual AMD 1400MHz with py2.2.2 and linux 2.4.19. By 'works', I mean that after 60sec, the program is still outputting spurts like this: 8 1066031758.16 5 1066031758.16 1 1066031758.16 7 1066031758.16 3 1066031758.16 6 1066031758.16 4 1066031758.16 2 1066031758.21 I am also available for running additional tests. My email is drewp at big asterisk .com less the spaces. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820605&group_id=5470 From noreply at sourceforge.net Tue Oct 14 09:30:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 09:30:23 2003 Subject: [Python-bugs-list] [ python-Bugs-823380 ] distutils: dir[ectory]_created Message-ID: Bugs item #823380, was opened at 2003-10-14 14:00 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823380&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lukasz Pankowski (lupan) >Assigned to: Thomas Heller (theller) Summary: distutils: dir[ectory]_created Initial Comment: In docutils documentation in section `The Postinstallation script' (python/dist/src/Doc/dist/dist.tex) mensions function dir_created, while it should be directory_created (python/dist/src/PC/bdist_wininst/install.c). Grepping the CVS tree shows the inconsistency: lupan@psi:[~/local/python]$ find -type f -print0 | xargs -0 grep [ry]_created ./dist/src/Doc/dist/dist.tex:dir_created(pathname) ./dist/src/PC/bdist_wininst/install.c: {"directory_created", DirectoryCreated, METH_VARARGS, NULL}, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823380&group_id=5470 From noreply at sourceforge.net Tue Oct 14 09:32:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 09:32:51 2003 Subject: [Python-bugs-list] [ python-Bugs-823405 ] Problems with msvcirt.dll in Windows 98 SE Message-ID: Bugs item #823405, was opened at 2003-10-14 14:37 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823405&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Cleber Akira Nakandakare (cakira) >Assigned to: Thomas Heller (theller) Summary: Problems with msvcirt.dll in Windows 98 SE Initial Comment: Hi! After I installed Python 2.3.2 in my Windows 98 SE (Version 4.10.2222 A), I've got problems with the library msvcirt.dll (or msvcrt.dll, whatever). The problem is exactly described in http://support.microsoft.com/?kbid=296551 Uninstalling Python did not resolve the problem, so I copied a spare msvcirt.dll (and only this file) to c:\windows\system and it looks everything works now. If you have any questions, send me an e-mail at cnakanda_at_fee.unicamp.br. Akira ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823405&group_id=5470 From noreply at sourceforge.net Tue Oct 14 09:34:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 09:34:58 2003 Subject: [Python-bugs-list] [ python-Bugs-820605 ] tkinter's 'after' and 'threads' on multiprocessor Message-ID: Bugs item #820605, was opened at 2003-10-09 15:15 Message generated for change (Settings changed) made by zoranbosnjak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820605&group_id=5470 Category: Tkinter Group: Platform-specific Status: Open >Resolution: Fixed Priority: 5 Submitted By: Zoran Bosnjak (zoranbosnjak) Assigned to: Martin v. L?wis (loewis) Summary: tkinter's 'after' and 'threads' on multiprocessor Initial Comment: I have attached simple testfile which works fine on single processor machine, but it does not work on multiprocessor machine (dual XEON - HT 2x 2.4GHz, python 2.1.1 (or python 2.2), RedHat 9.0 distr., linux-kernel 2.4.20-20-9smp). At the moment I can not tell where the problem is. It could be - in python core, - in threading module - in tkinter, TCL, Tk - in linux kernel Problem description: - I use tkinter's (Tk's) after method for periodic calls - I also start a few dummy threads which have nothong to do with tkinter. - (see the attached file) - After a while, one or more threads stop running and 'after' method stops working (they simply block). The situation is different each time I run the script. The problem is random and probability raises with number of threads. Normaly the problem occours after a few seconds with 8 threads. I am willing to run additional tests if someone has any idea where to start debugging. regards, Zoran Bosnjak ---------------------------------------------------------------------- Comment By: Zoran Bosnjak (zoranbosnjak) Date: 2003-10-14 15:29 Message: Logged In: YES user_id=583469 I couldn't reproduce this bug under python2.3.2 any more (with the same testprogram). ---------------------------------------------------------------------- Comment By: Drew Perttula (drewp) Date: 2003-10-13 21:28 Message: Logged In: YES user_id=127598 I forgot to show the after loop's output, which appears in random positions among the other threads' output. The more complete version of the output I see looks like this: 3 1066073253.53 1066073253.53 1066073253.53 7 4 1066073253.53 5 1066073253.53 1 1066073253.53 6 1066073253.53 2 1066073253.58 8 1066073253.85 1066073254.03 1 1066073254.03 2 1066073254.03 5 1066073254.03 So, no bug confirmation yet. ---------------------------------------------------------------------- Comment By: Drew Perttula (drewp) Date: 2003-10-13 09:59 Message: Logged In: YES user_id=127598 The given test program works for me on a dual AMD 1400MHz with py2.2.2 and linux 2.4.19. By 'works', I mean that after 60sec, the program is still outputting spurts like this: 8 1066031758.16 5 1066031758.16 1 1066031758.16 7 1066031758.16 3 1066031758.16 6 1066031758.16 4 1066031758.16 2 1066031758.21 I am also available for running additional tests. My email is drewp at big asterisk .com less the spaces. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820605&group_id=5470 From noreply at sourceforge.net Tue Oct 14 09:36:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 09:36:20 2003 Subject: [Python-bugs-list] [ python-Bugs-820605 ] tkinter's 'after' and 'threads' on multiprocessor Message-ID: Bugs item #820605, was opened at 2003-10-09 15:15 Message generated for change (Settings changed) made by zoranbosnjak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820605&group_id=5470 Category: Tkinter Group: Platform-specific >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Zoran Bosnjak (zoranbosnjak) Assigned to: Martin v. L?wis (loewis) Summary: tkinter's 'after' and 'threads' on multiprocessor Initial Comment: I have attached simple testfile which works fine on single processor machine, but it does not work on multiprocessor machine (dual XEON - HT 2x 2.4GHz, python 2.1.1 (or python 2.2), RedHat 9.0 distr., linux-kernel 2.4.20-20-9smp). At the moment I can not tell where the problem is. It could be - in python core, - in threading module - in tkinter, TCL, Tk - in linux kernel Problem description: - I use tkinter's (Tk's) after method for periodic calls - I also start a few dummy threads which have nothong to do with tkinter. - (see the attached file) - After a while, one or more threads stop running and 'after' method stops working (they simply block). The situation is different each time I run the script. The problem is random and probability raises with number of threads. Normaly the problem occours after a few seconds with 8 threads. I am willing to run additional tests if someone has any idea where to start debugging. regards, Zoran Bosnjak ---------------------------------------------------------------------- Comment By: Zoran Bosnjak (zoranbosnjak) Date: 2003-10-14 15:29 Message: Logged In: YES user_id=583469 I couldn't reproduce this bug under python2.3.2 any more (with the same testprogram). ---------------------------------------------------------------------- Comment By: Drew Perttula (drewp) Date: 2003-10-13 21:28 Message: Logged In: YES user_id=127598 I forgot to show the after loop's output, which appears in random positions among the other threads' output. The more complete version of the output I see looks like this: 3 1066073253.53 1066073253.53 1066073253.53 7 4 1066073253.53 5 1066073253.53 1 1066073253.53 6 1066073253.53 2 1066073253.58 8 1066073253.85 1066073254.03 1 1066073254.03 2 1066073254.03 5 1066073254.03 So, no bug confirmation yet. ---------------------------------------------------------------------- Comment By: Drew Perttula (drewp) Date: 2003-10-13 09:59 Message: Logged In: YES user_id=127598 The given test program works for me on a dual AMD 1400MHz with py2.2.2 and linux 2.4.19. By 'works', I mean that after 60sec, the program is still outputting spurts like this: 8 1066031758.16 5 1066031758.16 1 1066031758.16 7 1066031758.16 3 1066031758.16 6 1066031758.16 4 1066031758.16 2 1066031758.21 I am also available for running additional tests. My email is drewp at big asterisk .com less the spaces. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820605&group_id=5470 From noreply at sourceforge.net Tue Oct 14 10:09:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 10:09:21 2003 Subject: [Python-bugs-list] [ python-Bugs-823328 ] urllib2 digest auth is broken Message-ID: Bugs item #823328, was opened at 2003-10-14 10:03 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 digest auth is broken Initial Comment: The urllib2 digest auth support is busted. For starters, it's looking for a header 'Authorization' with the auth header in it - the correct header is WWW-Authenticate, according to rfc2617 (and confirmed by the "what does apache do?" test). Even after making this fix, auth is still failing, not sure why yet. I'm not convinced, looking at the code, that it could have _ever_ worked. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 13:18 Message: Logged In: YES user_id=29957 The following patch gives us a urllib2 that supports digest auth again. I've tested against Apache-2..0.47, if someone wants to suggest another webserver to check with, please let me know. We now support RFC2617-compliant versions of digest auth. I have no idea what the code that was in there was trying to do, but it was broken all over the place - there is no way it would have worked. Note the following limitations: - We are sending a client nonce, but we're not checking the Authentication-Info that's coming back. - qop="auth-int" support is shaky. But apache looks like it doesn't support it properly, anyway. And it's no shakier than it was - algorithm="MD5-sess" isn't properly supported, but then, it wasn't before, either. - the code now has a limit of 5 failures in a row before it bails out . there was no limit previously, so it would recurse until the recursion limit was hit. I can't test the old code, unfortunately, but I _believe_ I've made it work again. It certainly could not have worked as it was. I've also not tested proxy-digest-auth - suggestions for a proxy server to try? Assuming my reading of the RFC is right, it should "just work". ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 12:16 Message: Logged In: YES user_id=29957 Ok, we're not handling the qop=auth style of Digest, as specified in the RFC. I'm working on it now. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 10:12 Message: Logged In: YES user_id=29957 Hm. Looking through comments, it's possible that this used to work with an older, broken, apache digest mode. It certainly fails with 2.0.47... :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 From noreply at sourceforge.net Tue Oct 14 13:29:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 13:29:16 2003 Subject: [Python-bugs-list] [ python-Bugs-818029 ] installer wakes up Windows File Protection Message-ID: Bugs item #818029, was opened at 2003-10-05 10:49 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pete (thegoldenear) >Assigned to: Thomas Heller (theller) Summary: installer wakes up Windows File Protection Initial Comment: installing Python 2.3.2 on Windows 2000 SP4 induced the Windows File Protection, presumably bcos an existing system file had been replaced by an older version ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-10-14 19:29 Message: Logged In: YES user_id=11105 It seems I did include msvcrt.dll and msvcirt.dll from my system directory, but probably the files from VC6 SP5 should be included. IMO msvcirt.dll is not used by Python, but msvcirt.dll uses msvcrt.dll, so it makes sense to include both of these files in the installer. Here are the version numbers I found in the various installers: Python-2.3.exe: msvcrt.dll - 6.1.8637.0, msvcirt.dll - 6.1.8168.0 Python-2.3.2.exe: msvcrt.dll - 7.0.2600.1106, msvcirt.dll - 7.0.2600.0 vcredist.exe: msvcrt.dll - 6.0.8797.0, msvcirt.dll - 6.0.8168.0 The vcredist.exe is from the VC6 SP5 CD. I will include the latter files in the next installer (2.3.3), and hopefully everything will be ok then. Assigned back to myself. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-06 17:50 Message: Logged In: YES user_id=31435 msvcirt.dll was in the installer when I inherited it from Guido. He probably inherited it from Mark (Hammond). If Mark can't remember why it's there either, we should check all the .pyd (not just python23.dll) for references to it. Assigned to Mark. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-06 17:38 Message: Logged In: YES user_id=11105 I *can* reproduce it - look into the event viewer, category 'System': File replacement was attempted on the protected system file d:\winnt\system32\msvcirt.dll... The windows installer tries (in my case) to replace the version 6.1.8637.0 with 7.0.2600.0. Looking at python23.dll's dependencies with Dependency Walker, it seems that msvcirt.dll isn't required by Python at all, so the solution would be simple: leave msvcirt.dll out of the installer. Why is it in the installer at all? Tim? ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-10-05 23:21 Message: Logged In: YES user_id=699438 I couldn't reproduce this on a stock install of W2K SP 4. If you're in a position to do so (you'll need the physical CD media), could you rebuild your DLL cache? From the command-line "sfc /purgecache && sfc /scannow" should do this. After that, try to install python2.3.2 and see if sfc kicks in again. If you can't do that, you might want to see if the file python23.dll somehow manually ended up in the %windir% \system32\dllcache directory. As far as I know, thats the only file that should be getting shoved into an area the sfc cares about. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-05 20:12 Message: Logged In: YES user_id=31435 Changed category to Windows and assigned to Thomas Heller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 From noreply at sourceforge.net Tue Oct 14 13:30:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 13:30:54 2003 Subject: [Python-bugs-list] [ python-Bugs-823405 ] Problems with msvcirt.dll in Windows 98 SE Message-ID: Bugs item #823405, was opened at 2003-10-14 14:37 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823405&group_id=5470 Category: Installation Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Cleber Akira Nakandakare (cakira) Assigned to: Thomas Heller (theller) Summary: Problems with msvcirt.dll in Windows 98 SE Initial Comment: Hi! After I installed Python 2.3.2 in my Windows 98 SE (Version 4.10.2222 A), I've got problems with the library msvcirt.dll (or msvcrt.dll, whatever). The problem is exactly described in http://support.microsoft.com/?kbid=296551 Uninstalling Python did not resolve the problem, so I copied a spare msvcirt.dll (and only this file) to c:\windows\system and it looks everything works now. If you have any questions, send me an e-mail at cnakanda_at_fee.unicamp.br. Akira ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-10-14 19:30 Message: Logged In: YES user_id=11105 This is certainly a duplicate of bug 818029, although the symptoms are somewhat different. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823405&group_id=5470 From noreply at sourceforge.net Tue Oct 14 13:56:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 13:56:22 2003 Subject: [Python-bugs-list] [ python-Bugs-821948 ] fcntl() not working on sparc/linux (python 2.2.3) Message-ID: Bugs item #821948, was opened at 2003-10-12 00:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Alberto Bertogli (albertogli) Assigned to: Nobody/Anonymous (nobody) Summary: fcntl() not working on sparc/linux (python 2.2.3) Initial Comment: In sparc, fcntl.fcntl() is not working properly under Python 2.2.3; a simple strace of: import fcntl, sys fcntl.fcntl(sys.stdin.fileno(), fcntl.F_SETFL, os.O_NONBLOCK) will reveal that on sparc there's no fcntl() syscall done, while under x86 it works as expected (ie. the syscall is there). I have not tested yet with Python 2.3 but I'll let you know when I do. Thanks, Alberto ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-14 19:56 Message: Logged In: YES user_id=21627 I can't see anything strange in the assembler code. Also, from looking both at the source code, and the assembler code, there is absolutely no code path which could cause fcntl *not* to be called, except if an exception is raised. Can you run this in a debugger, setting a break-point on fcntl_fcntl, and see how it steps through the code? ---------------------------------------------------------------------- Comment By: Alberto Bertogli (albertogli) Date: 2003-10-14 05:31 Message: Logged In: YES user_id=44390 I'm attaching both, tar.bz2 compressed, about 45k, without any stripping whatsoever. Linux on Sparc userspace is always 32 bit, but the kernel is 64 bit on sparc64 and 32 bit on sparc32. In this case, userspace is 32 bit and kernel 64 bit. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-13 23:33 Message: Logged In: YES user_id=21627 It would be good if you could attach preprocessor output and assembler code (both obtained through --save-temps) for fcntlmodule.c. If this is too large to attach you might need to compress it, if it is then still too large, you would need to strip all but fcntl_fcntl. Also, are you using a 32-bit or a 64-bit compiler? ---------------------------------------------------------------------- Comment By: Alberto Bertogli (albertogli) Date: 2003-10-13 19:06 Message: Logged In: YES user_id=44390 I'm sorry I didn't specify earlier, this is a box running Linux (gentoo distribution) with: Linux Kernel 2.4.20 glibc 2.2.5 gcc 2.95.3 python 2.2.3 The fragment of the strace output is the following, it's between I press the final '\n' and the response '0\n' appears: write(1, "\n", 1) = 1 rt_sigprocmask(SIG_BLOCK, [INT], [32], 8) = 0 ioctl(0, 0x8024540a, {B38400 opost isig icanon echo ...}) = 0 rt_sigprocmask(SIG_SETMASK, [32], NULL, 8) = 0 rt_sigaction(SIGINT, {0x700486f8, [], 0}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTERM, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGQUIT, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGALRM, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTSTP, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTTOU, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGTTIN, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGWINCH, {SIG_DFL}, {0x700486f8, [], 0}, 0x701431c8, 8) = 0 rt_sigaction(SIGINT, NULL, {0x700486f8, [], 0}, 0, 8) = 0 rt_sigaction(SIGINT, {0x700486f8, [], 0}, NULL, 0x701431c8, 8) = 0 nfssvc(0) = 0 write(1, "0\n", 2) = 2 On x86 the fcntl64() syscall happens right before the write(). I don't think the bug is present in earlier versions of Python because I remember this used to work fine before the upgrade, however I can't pinpoint the exact release this started to show up. Let me know if you need additional info or want me to do some tests. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-12 19:41 Message: Logged In: YES user_id=21627 I cannot reproduce this. My binary of 2.2.1 does read(3, "import fcntl, sys, os\nfcntl.fcnt"..., 8192) = 84 read(3, "", 8192) = 0 llseek(3, 0, SEEK_CUR) = 0 close(3) = 0 fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(24, 3), ...}) = 0 fcntl(0, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 sigaction(SIGINT, NULL, {0xff25ff24, ~[KILL STOP], 0}) = 0 sigaction(SIGINT, {SIG_DFL}, NULL) = 0 Can you attach your strace output? Can you also try truss? What Solaris version and patches, what compiler? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=821948&group_id=5470 From noreply at sourceforge.net Tue Oct 14 14:07:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 14:07:26 2003 Subject: [Python-bugs-list] [ python-Bugs-818029 ] installer wakes up Windows File Protection Message-ID: Bugs item #818029, was opened at 2003-10-05 04:49 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pete (thegoldenear) Assigned to: Thomas Heller (theller) Summary: installer wakes up Windows File Protection Initial Comment: installing Python 2.3.2 on Windows 2000 SP4 induced the Windows File Protection, presumably bcos an existing system file had been replaced by an older version ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-14 14:07 Message: Logged In: YES user_id=31435 While we're at it, I'd like to question whether we should be shipping MS dlls at all. I'd *like* to question it, but have never known how to : I don't know that it's necessary to ship them, especially since we don't support DOS directly anymore. OTOH, I don't know that no box out there needs them either. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-14 13:29 Message: Logged In: YES user_id=11105 It seems I did include msvcrt.dll and msvcirt.dll from my system directory, but probably the files from VC6 SP5 should be included. IMO msvcirt.dll is not used by Python, but msvcirt.dll uses msvcrt.dll, so it makes sense to include both of these files in the installer. Here are the version numbers I found in the various installers: Python-2.3.exe: msvcrt.dll - 6.1.8637.0, msvcirt.dll - 6.1.8168.0 Python-2.3.2.exe: msvcrt.dll - 7.0.2600.1106, msvcirt.dll - 7.0.2600.0 vcredist.exe: msvcrt.dll - 6.0.8797.0, msvcirt.dll - 6.0.8168.0 The vcredist.exe is from the VC6 SP5 CD. I will include the latter files in the next installer (2.3.3), and hopefully everything will be ok then. Assigned back to myself. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-06 11:50 Message: Logged In: YES user_id=31435 msvcirt.dll was in the installer when I inherited it from Guido. He probably inherited it from Mark (Hammond). If Mark can't remember why it's there either, we should check all the .pyd (not just python23.dll) for references to it. Assigned to Mark. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-06 11:38 Message: Logged In: YES user_id=11105 I *can* reproduce it - look into the event viewer, category 'System': File replacement was attempted on the protected system file d:\winnt\system32\msvcirt.dll... The windows installer tries (in my case) to replace the version 6.1.8637.0 with 7.0.2600.0. Looking at python23.dll's dependencies with Dependency Walker, it seems that msvcirt.dll isn't required by Python at all, so the solution would be simple: leave msvcirt.dll out of the installer. Why is it in the installer at all? Tim? ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-10-05 17:21 Message: Logged In: YES user_id=699438 I couldn't reproduce this on a stock install of W2K SP 4. If you're in a position to do so (you'll need the physical CD media), could you rebuild your DLL cache? From the command-line "sfc /purgecache && sfc /scannow" should do this. After that, try to install python2.3.2 and see if sfc kicks in again. If you can't do that, you might want to see if the file python23.dll somehow manually ended up in the %windir% \system32\dllcache directory. As far as I know, thats the only file that should be getting shoved into an area the sfc cares about. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-05 14:12 Message: Logged In: YES user_id=31435 Changed category to Windows and assigned to Thomas Heller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 From noreply at sourceforge.net Tue Oct 14 14:17:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 14:17:33 2003 Subject: [Python-bugs-list] [ python-Bugs-818029 ] installer wakes up Windows File Protection Message-ID: Bugs item #818029, was opened at 2003-10-05 10:49 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pete (thegoldenear) Assigned to: Thomas Heller (theller) Summary: installer wakes up Windows File Protection Initial Comment: installing Python 2.3.2 on Windows 2000 SP4 induced the Windows File Protection, presumably bcos an existing system file had been replaced by an older version ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-10-14 20:17 Message: Logged In: YES user_id=11105 The clearest description *how* to ship these dlls I did find here: http://www.jrsoftware.org/ishowto.phtml?a=vc Of course, this doesn't answer the question *whether* they should be distributed at all. And I do know that on a clean Win95 system the MFC dlls were not present, unless write (aka wordpad) was installed. Don't remember anymore if this also applied to msvcrt.dll. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-14 20:07 Message: Logged In: YES user_id=31435 While we're at it, I'd like to question whether we should be shipping MS dlls at all. I'd *like* to question it, but have never known how to : I don't know that it's necessary to ship them, especially since we don't support DOS directly anymore. OTOH, I don't know that no box out there needs them either. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-14 19:29 Message: Logged In: YES user_id=11105 It seems I did include msvcrt.dll and msvcirt.dll from my system directory, but probably the files from VC6 SP5 should be included. IMO msvcirt.dll is not used by Python, but msvcirt.dll uses msvcrt.dll, so it makes sense to include both of these files in the installer. Here are the version numbers I found in the various installers: Python-2.3.exe: msvcrt.dll - 6.1.8637.0, msvcirt.dll - 6.1.8168.0 Python-2.3.2.exe: msvcrt.dll - 7.0.2600.1106, msvcirt.dll - 7.0.2600.0 vcredist.exe: msvcrt.dll - 6.0.8797.0, msvcirt.dll - 6.0.8168.0 The vcredist.exe is from the VC6 SP5 CD. I will include the latter files in the next installer (2.3.3), and hopefully everything will be ok then. Assigned back to myself. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-06 17:50 Message: Logged In: YES user_id=31435 msvcirt.dll was in the installer when I inherited it from Guido. He probably inherited it from Mark (Hammond). If Mark can't remember why it's there either, we should check all the .pyd (not just python23.dll) for references to it. Assigned to Mark. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-06 17:38 Message: Logged In: YES user_id=11105 I *can* reproduce it - look into the event viewer, category 'System': File replacement was attempted on the protected system file d:\winnt\system32\msvcirt.dll... The windows installer tries (in my case) to replace the version 6.1.8637.0 with 7.0.2600.0. Looking at python23.dll's dependencies with Dependency Walker, it seems that msvcirt.dll isn't required by Python at all, so the solution would be simple: leave msvcirt.dll out of the installer. Why is it in the installer at all? Tim? ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-10-05 23:21 Message: Logged In: YES user_id=699438 I couldn't reproduce this on a stock install of W2K SP 4. If you're in a position to do so (you'll need the physical CD media), could you rebuild your DLL cache? From the command-line "sfc /purgecache && sfc /scannow" should do this. After that, try to install python2.3.2 and see if sfc kicks in again. If you can't do that, you might want to see if the file python23.dll somehow manually ended up in the %windir% \system32\dllcache directory. As far as I know, thats the only file that should be getting shoved into an area the sfc cares about. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-05 20:12 Message: Logged In: YES user_id=31435 Changed category to Windows and assigned to Thomas Heller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 From noreply at sourceforge.net Tue Oct 14 16:04:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 16:04:59 2003 Subject: [Python-bugs-list] [ python-Bugs-823672 ] os.strerror doesn't understand windows error codes Message-ID: Bugs item #823672, was opened at 2003-10-14 22: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=823672&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: os.strerror doesn't understand windows error codes Initial Comment: For example, os.strerror(errno.EWOULDBLOCK) returns 'unknown error'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823672&group_id=5470 From noreply at sourceforge.net Tue Oct 14 17:49:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 17:50:04 2003 Subject: [Python-bugs-list] [ python-Bugs-726911 ] platform module needs docs (LaTeX) Message-ID: Bugs item #726911, was opened at 2003-04-24 07:22 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726911&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Brett Cannon (bcannon) Summary: platform module needs docs (LaTeX) Initial Comment: The platform module needs to be documented in the Library Reference. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-10-14 14:49 Message: Logged In: YES user_id=357491 Patch #785752 was applied which closes this bug. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-10-11 21:49 Message: Logged In: YES user_id=357491 Just to cross-reference, patch #785752 is someone's attempt at this. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-08-04 19:45 Message: Logged In: YES user_id=3066 We have a volunteer! Just check it in when you're ready, Brett. I'll be glad to make any ancilliary updates if you're not able to test the LaTeX yourself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=726911&group_id=5470 From noreply at sourceforge.net Tue Oct 14 18:30:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 14 18:30:57 2003 Subject: [Python-bugs-list] [ python-Bugs-780461 ] MacOS.Error for platform.mac_ver under OS X Message-ID: Bugs item #780461, was opened at 2003-07-30 13:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780461&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: M.-A. Lemburg (lemburg) Summary: MacOS.Error for platform.mac_ver under OS X Initial Comment: >>> platform.mac_ver() Traceback (most recent call last): File "", line 1, in ? File "/Users/drifty/cvs_code/lib/python2.3/platform.py", line 563, in mac_ver sysv,sysu,sysa = _mac_ver_lookup(('sysv','sysu','sysa')) File "/Users/drifty/cvs_code/lib/python2.3/platform.py", line 532, in _mac_ver_lookup append(gestalt(selector)) MacOS.Error: (-5551, 'undefined selector was passed to Gestalt') This is on an OS X 10.2.6 system. Any chance this is because I compiled with --enable- unicode=ucs4 ? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-10-14 15:30 Message: Logged In: YES user_id=357491 Well, this is working for me under 2.4 (still busted under 2.3, though). But a quick check of the cvs logs and it turns out Jack wanted this backported but just didn't get to it. So I will go ahead and backport the changes from 1.6 and 1.7 to release23-maint. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-07 19:28 Message: Logged In: YES user_id=357491 I have no clue how to get the info but I can help test anything. I think Jack is going to have to be the big helper in terms of how to patch this one. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-08-01 04:40 Message: Logged In: YES user_id=38388 Catching MacOS.Error doesn't help much: if 'sysu' is not available on MacOSX, then I need the system information from somewhere else. Any hints ? (don't have a MacOSX to test on, so it's up to you to provide the necessary information or patch :-) Thanks. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-01 02:40 Message: Logged In: YES user_id=45365 The problem is not with your ucs4 build, this call always fails under MacOSX. The problem is that the 'sysu' gestalt selector isn't available under OSX. The code in _mac_ver_lookup does a try/except on RuntimeError around the call to gestalt, but I don't remember MacOS.Error ever being a subclass of RuntimeError. Currently MacOS.Error is in a class by itself, it should probably be an OSError subclass, but that still won't fix this. I suggest doing the try/except on MacOS.Error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780461&group_id=5470 From noreply at sourceforge.net Wed Oct 15 03:15:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 03:16:03 2003 Subject: [Python-bugs-list] [ python-Bugs-783312 ] Serious mem leak in socket module Message-ID: Bugs item #783312, was opened at 2003-08-05 06:13 Message generated for change (Comment added) made by iscorinne You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783312&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: David Rushby (woodsplitter) Assigned to: Martin v. L?wis (loewis) Summary: Serious mem leak in socket module Initial Comment: There are memory leaks in Python 2.3's socketmodule.c:getsockaddrarg function. In the AF_INET clause of that function's switch, the PyArg_ParseTuple format was changed from "si:getsockaddrarg" in 2.2 to "eti:getsockaddrarg" in 2.3; in the AF_INET6 clause, the format was changed from "si|ii" in 2.2 to "eti|ii" in 2.3. The memory leak occurs because the "s" extractor did not allocate any memory that needed to be manually freed, whereas "et" does, yet no provision was added to free the newly allocated memory. Looks like this bug was introduced in CVS revision 1.259: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modules/socketmodule.c.diff?r1=1.258&r2=1.259 I've attached a test program that demonstrates the leak, plus a patch to socketmodule.c in unified diff format. To me, this leak seems serious because it affects virtually every Python program that uses the socket module (getsockaddrarg is called by the socket.socket methods bind, connect, connect_ex, and sendto). ---------------------------------------------------------------------- Comment By: iscorinne (iscorinne) Date: 2003-10-15 07:15 Message: Logged In: YES user_id=887306 h?tten Sie halt mal gleich mich gefragt... iscorinne ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-07 11:57 Message: Logged In: YES user_id=21627 Thanks for the report. I have applied a similar patch, in socketmodule.c 1.273 and 1.271.6.2, NEWS 1.831.4.9. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-08-06 05:56 Message: Logged In: YES user_id=80475 This was Martin's change (adding IDNA support). Assigning to him to approve your patch. ---------------------------------------------------------------------- Comment By: Gottfried Stauffenberg (gottfried) Date: 2003-08-05 20:35 Message: Logged In: YES user_id=838410 Since I have installed Python 2.3 Final (on Windows XP Professional) I have got a serious problem in my data uploading scripts to a SAP 7.4 Database on a different server. Python crashes with no traceback available and Windows notifies me of an serious program crash. The amount of data being send before the crash is variable, it can be anything between 100KB and 508KB of SQL INSERT statements (according to my application log file). I am not sure if the memory leak causes the program to crash, however this might be a possible explanation There had been no problems in 2.2.3. with about 300 MB of sql statements. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783312&group_id=5470 From noreply at sourceforge.net Wed Oct 15 06:05:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 06:05:50 2003 Subject: [Python-bugs-list] [ python-Bugs-824016 ] MSVCRT.DLL screws up the system Message-ID: Bugs item #824016, was opened at 2003-10-15 13: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=824016&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Petter Holmstr?m (pholmstrom) Assigned to: Thomas Heller (theller) Summary: MSVCRT.DLL screws up the system Initial Comment: This applies to the Windows version of Python 2.3.2. When a friend of mine installed Python onto his computer (running Windows NT 4) the entire system got screwed up and he had to reinstall the operating system and all applications. The errors reported all had to do with unresolved symbols in the MSVCRT.DLL -file. Uninstalling Python did not help. I also encountered a similar problem. After installing Python on a Windows NT 4 machine Quattro Pro 9 would not start, complaining about unresolved symbols in the MSVCRT.DLL -file. When I uninstalled Python and rolled back the changes QP started just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824016&group_id=5470 From noreply at sourceforge.net Wed Oct 15 16:17:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 16:17:22 2003 Subject: [Python-bugs-list] [ python-Bugs-822668 ] tarfile exception on large .tar files Message-ID: Bugs item #822668, was opened at 2003-10-13 13:20 Message generated for change (Comment added) made by johahn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=822668&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Johan Fredrik ?hman (johanfo) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile exception on large .tar files Initial Comment: The following exception is thrown when I write a lot of data > 10Gb directly to my tapestreamer. Is this normal? Traceback (most recent call last): File "/usr/local/metroField/fieldPlugins/Backup.py", line 184, in run self._doBackup() File "/usr/local/metroField/fieldPlugins/Backup.py", line 333, in _doBackup arc.close() File "/usr/local/metroField/fieldPlugins/Backup.py", line 533, in close self.tf.close() File "/usr/local/lib/python2.3/tarfile.py", line 1009, in close self.fileobj.close() File "/usr/local/lib/python2.3/tarfile.py", line 360, in close self.fileobj.write(struct.pack(" sys. maxint*2+2, that is for files larger than 4Gb. This is not good since the newest tar and gzip versions can handle files larger than that. According to the gzip file format spec from www.wotsit.org, the last 4 bytes of a gzip file "contains the size of the original (uncompressed) input data modulo 2^32". All that has to be done is to perform this calculation prior to the call to struct. pack. Here is my proposed fix: 358: if self.type == "gz": 359: self.fileobj.write(struct.pack(" Bugs item #824371, was opened at 2003-10-15 16: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=824371&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: ntpath.expandvars doesn't expand Windows-style variables. Initial Comment: ntpath.expandvars is exactly the same as posixpath.expandvars -- it only expands $vars. But in windows, environment variables are represented by %vars%, not $vars. I can write a patch if necessary. Having read the code, I noticed that it went to great lengths to do what could quite easily be done with a regular expression, so I assume using regular expressions isn't kosher in the *path modules? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824371&group_id=5470 From noreply at sourceforge.net Wed Oct 15 17:13:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 17:13:45 2003 Subject: [Python-bugs-list] [ python-Bugs-818029 ] installer wakes up Windows File Protection Message-ID: Bugs item #818029, was opened at 2003-10-05 10:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pete (thegoldenear) Assigned to: Thomas Heller (theller) Summary: installer wakes up Windows File Protection Initial Comment: installing Python 2.3.2 on Windows 2000 SP4 induced the Windows File Protection, presumably bcos an existing system file had been replaced by an older version ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-15 23:13 Message: Logged In: YES user_id=21627 The answer for the "why" probably is that Win95, out of the box, does not include msvcrt.dll (only msvcrt20.dll and msvcrt40.dll). Many users of Win95 probably have msvcrt.dll because they have installed MS Office or some other software including it. Any kind of patch to Win95 (including Win95B) installs msvcrt.dll also. To solve this problem, I would suggest to discontinue support for Win95 in Python 2.4. But then, I also suggest to use VC7.1 for Python2.4, which brings up the issue of distributing MSVCR71.dll... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-14 20:17 Message: Logged In: YES user_id=11105 The clearest description *how* to ship these dlls I did find here: http://www.jrsoftware.org/ishowto.phtml?a=vc Of course, this doesn't answer the question *whether* they should be distributed at all. And I do know that on a clean Win95 system the MFC dlls were not present, unless write (aka wordpad) was installed. Don't remember anymore if this also applied to msvcrt.dll. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-14 20:07 Message: Logged In: YES user_id=31435 While we're at it, I'd like to question whether we should be shipping MS dlls at all. I'd *like* to question it, but have never known how to : I don't know that it's necessary to ship them, especially since we don't support DOS directly anymore. OTOH, I don't know that no box out there needs them either. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-14 19:29 Message: Logged In: YES user_id=11105 It seems I did include msvcrt.dll and msvcirt.dll from my system directory, but probably the files from VC6 SP5 should be included. IMO msvcirt.dll is not used by Python, but msvcirt.dll uses msvcrt.dll, so it makes sense to include both of these files in the installer. Here are the version numbers I found in the various installers: Python-2.3.exe: msvcrt.dll - 6.1.8637.0, msvcirt.dll - 6.1.8168.0 Python-2.3.2.exe: msvcrt.dll - 7.0.2600.1106, msvcirt.dll - 7.0.2600.0 vcredist.exe: msvcrt.dll - 6.0.8797.0, msvcirt.dll - 6.0.8168.0 The vcredist.exe is from the VC6 SP5 CD. I will include the latter files in the next installer (2.3.3), and hopefully everything will be ok then. Assigned back to myself. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-06 17:50 Message: Logged In: YES user_id=31435 msvcirt.dll was in the installer when I inherited it from Guido. He probably inherited it from Mark (Hammond). If Mark can't remember why it's there either, we should check all the .pyd (not just python23.dll) for references to it. Assigned to Mark. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-06 17:38 Message: Logged In: YES user_id=11105 I *can* reproduce it - look into the event viewer, category 'System': File replacement was attempted on the protected system file d:\winnt\system32\msvcirt.dll... The windows installer tries (in my case) to replace the version 6.1.8637.0 with 7.0.2600.0. Looking at python23.dll's dependencies with Dependency Walker, it seems that msvcirt.dll isn't required by Python at all, so the solution would be simple: leave msvcirt.dll out of the installer. Why is it in the installer at all? Tim? ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-10-05 23:21 Message: Logged In: YES user_id=699438 I couldn't reproduce this on a stock install of W2K SP 4. If you're in a position to do so (you'll need the physical CD media), could you rebuild your DLL cache? From the command-line "sfc /purgecache && sfc /scannow" should do this. After that, try to install python2.3.2 and see if sfc kicks in again. If you can't do that, you might want to see if the file python23.dll somehow manually ended up in the %windir% \system32\dllcache directory. As far as I know, thats the only file that should be getting shoved into an area the sfc cares about. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-05 20:12 Message: Logged In: YES user_id=31435 Changed category to Windows and assigned to Thomas Heller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 From noreply at sourceforge.net Wed Oct 15 17:39:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 17:39:29 2003 Subject: [Python-bugs-list] [ python-Bugs-824417 ] exception with Message.get_filename() Message-ID: Bugs item #824417, was opened at 2003-10-15 17: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=824417&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: exception with Message.get_filename() Initial Comment: The following scriptlet: -----------t.py----------------- import sys import email msg = email.message_from_file(sys.stdin) for part in msg.walk(): print part.get_params() print part.get_filename() -------------------------------- gets an exception when fed the attached email (extracted from a real life non-spam message). $ python2 t.py Bugs item #824430, was opened at 2003-10-15 15: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=824430&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Larry Meyn (lmeyn) Assigned to: Jack Jansen (jackjansen) Summary: Package Manager Scrolling Behavior Initial Comment: The Package Manager scroll bar always jumps to the top of the list after being moved. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824430&group_id=5470 From noreply at sourceforge.net Wed Oct 15 18:01:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 18:02:05 2003 Subject: [Python-bugs-list] [ python-Bugs-817611 ] Google kills socket lookup Message-ID: Bugs item #817611, was opened at 2003-10-04 11:11 Message generated for change (Comment added) made by johahn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817611&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerd Schulz (spikeee) Assigned to: Nobody/Anonymous (nobody) Summary: Google kills socket lookup Initial Comment: Just test: >>> socket.gethostbyname('www.google.com') '216.239.39.99' >>> socket.gethostbyaddr('216.239.39.99') Traceback (most recent call last): File "", line 1, in ? herror: (11004, 'host not found') Don't know why. Maybe of this strange akadns-stuff?!?! He struggles around for quite a time before he comes to the error, maybe to much or cyclic input. Cheers, Spikeee ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-16 00:01 Message: Logged In: YES user_id=887415 Good answer. Since this is not a bug I suggest Gert or someone removes it from the bug list. Does anyone know of another forum for these kind of common non-bug questions? I could only think of posting to comp.lang.python/activestate's python-list for archival purpose. ...johahn ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-10-05 16:41 Message: Logged In: YES user_id=580910 This is not a bug/feature of the python socket module, but of DNS itself. DNS uses a seperate tree to find the name associated with an IP adres, there is no entry for the address associated with www.google.com. The same feature can be observed from the command-line: $ nslookup www.google.com ns.xs4all.nl Server: ns.xs4all.nl Address: 194.109.6.66#53 Non-authoritative answer: www.google.com canonical name = www.google.akadns.net. Name: www.google.akadns.net Address: 216.239.59.99 $ nslookup 216.239.59.99 ns.xs4all.nl Server: ns.xs4all.nl Address: 194.109.6.66#53 ** server can't find 99.59.239.216.in-addr.arpa: NXDOMAIN ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817611&group_id=5470 From noreply at sourceforge.net Wed Oct 15 18:05:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 18:05:53 2003 Subject: [Python-bugs-list] [ python-Bugs-824417 ] exception with Message.get_filename() Message-ID: Bugs item #824417, was opened at 2003-10-15 17:39 Message generated for change (Comment added) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824417&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: exception with Message.get_filename() Initial Comment: The following scriptlet: -----------t.py----------------- import sys import email msg = email.message_from_file(sys.stdin) for part in msg.walk(): print part.get_params() print part.get_filename() -------------------------------- gets an exception when fed the attached email (extracted from a real life non-spam message). $ python2 t.py Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-15 18:05 Message: Logged In: YES user_id=142072 The documentation for the get_param method suggests the following code when the value is a tuple: param = msg.get_param('foo') if isinstance(param, tuple): param = unicode(param[2], param[0]) The get_filename method follows this advice, but it doesn't work when the encoding is None. I fixed this by changing Message.get_filename to this: def get_filename(self, failobj=None): """Return the filename associated with the payload if present. The filename is extracted from the Content-Disposition header's `filename' parameter, and it is unquoted. """ missing = [] filename = self.get_param('filename', missing, 'content-disposition') if filename is missing: return failobj if isinstance(filename, TupleType): # It's an RFC 2231 encoded parameter newvalue = _unquotevalue(filename) if newvalue[0]: return unicode(newvalue[2], newvalue[0]) return unicode(newvalue[2]) else: newvalue = _unquotevalue(filename.strip()) return newvalue ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824417&group_id=5470 From noreply at sourceforge.net Wed Oct 15 19:44:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 15 19:44:46 2003 Subject: [Python-bugs-list] [ python-Bugs-817611 ] Google kills socket lookup Message-ID: Bugs item #817611, was opened at 2003-10-04 05:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817611&group_id=5470 Category: Python Library >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Gerd Schulz (spikeee) Assigned to: Nobody/Anonymous (nobody) Summary: Google kills socket lookup Initial Comment: Just test: >>> socket.gethostbyname('www.google.com') '216.239.39.99' >>> socket.gethostbyaddr('216.239.39.99') Traceback (most recent call last): File "", line 1, in ? herror: (11004, 'host not found') Don't know why. Maybe of this strange akadns-stuff?!?! He struggles around for quite a time before he comes to the error, maybe to much or cyclic input. Cheers, Spikeee ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-15 19:44 Message: Logged In: YES user_id=31435 Closed as 3rd-party, won't fix, which is the closest thing we have to "it's not a bug, but it's not Python's doing even if it were" . Asking for a tutorial about anything on c.l.py will usually get a decent response (Python-related or not). ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-15 18:01 Message: Logged In: YES user_id=887415 Good answer. Since this is not a bug I suggest Gert or someone removes it from the bug list. Does anyone know of another forum for these kind of common non-bug questions? I could only think of posting to comp.lang.python/activestate's python-list for archival purpose. ...johahn ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2003-10-05 10:41 Message: Logged In: YES user_id=580910 This is not a bug/feature of the python socket module, but of DNS itself. DNS uses a seperate tree to find the name associated with an IP adres, there is no entry for the address associated with www.google.com. The same feature can be observed from the command-line: $ nslookup www.google.com ns.xs4all.nl Server: ns.xs4all.nl Address: 194.109.6.66#53 Non-authoritative answer: www.google.com canonical name = www.google.akadns.net. Name: www.google.akadns.net Address: 216.239.59.99 $ nslookup 216.239.59.99 ns.xs4all.nl Server: ns.xs4all.nl Address: 194.109.6.66#53 ** server can't find 99.59.239.216.in-addr.arpa: NXDOMAIN ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817611&group_id=5470 From noreply at sourceforge.net Thu Oct 16 01:05:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 01:05:23 2003 Subject: [Python-bugs-list] [ python-Bugs-824565 ] bad value of INSTSONAME in Makefile Message-ID: Bugs item #824565, was opened at 2003-10-15 22: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=824565&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kyle Lanclos (lanclos) Assigned to: Nobody/Anonymous (nobody) Summary: bad value of INSTSONAME in Makefile Initial Comment: With the 2.3.2 source on a Solaris 9 machine and the following configure: ./configure --prefix=/opt/python-2.3.2 --enable-shared 'make; make install' will result in an error when the Makefile tries to link the .so file, because INSTSONAME = LDLIBRARY = libpython$(VERSION).so, and the linker tries to do: $(INSTALL_SHARED) libpython$(VERSION)$(SO) $(DESTDIR)$(LIBDIR)/$(INSTSONAME); (cd $(DESTDIR)$(LIBDIR); $(LN) -sf $(INSTSONAME) libpython$(VERSION)$(SO)); This is all fine and good, except that libpython$(VERSION)$(SO) is the same as INSTSONAME, and you end up doing: ln -sf libpython2.3.so libpython2.3.so ...which rightfully returns an error. Looking at the generated Makefile on Linux, the value of INSTSONAME is: INSTSONAME= libpython$(VERSION).so.1.0 ...instead of this value from Solaris: INSTSONAME= $(LDLIBRARY) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824565&group_id=5470 From noreply at sourceforge.net Thu Oct 16 07:51:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 07:51:47 2003 Subject: [Python-bugs-list] [ python-Bugs-824756 ] IDLE fails to start on Win2000 Message-ID: Bugs item #824756, was opened at 2003-10-16 11: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=824756&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE fails to start on Win2000 Initial Comment: The new python-2.3.2-1.exe has not fixed the IDLE problem. I have two Windows 2000 machines (not running firewalls) on which IDLE does not start. Python itself works perfectly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 From noreply at sourceforge.net Thu Oct 16 08:55:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 08:55:37 2003 Subject: [Python-bugs-list] [ python-Bugs-811294 ] dis.disassemble_string() broken Message-ID: Bugs item #811294, was opened at 2003-09-23 18:23 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) >Assigned to: Armin Rigo (arigo) Summary: dis.disassemble_string() broken Initial Comment: dis.disassemble_string(), called by dis.dis("some-bytecode-string"), still relies on the dead SET_LINENO opcode. I'll propose a patch for this at some later time. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-16 13:55 Message: Logged In: YES user_id=6656 I think I trust Armin on stuff like this ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-09-26 12:07 Message: Logged In: YES user_id=4771 Here is a patch with a separate generator function that enumerates all (offset, lineno) pairs, as they where in the compiler before they got obfuscated into lnotab. For simplicity, disassemble() just turns them into a dict, so it didn't really have to be a generator at all, but it is just nicer this way. Maybe pdb could use it too. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-09-26 11:20 Message: Logged In: YES user_id=4771 ah well. I didn't realize that disassemble_string() never tried to *display* line numbers. It only detects SET_LINENO so that it can write a nice blank line before it. Attached a patch that removes this behavior (no longer possible in a function that doesn't have access to a co_lnotab). I'll submit another more constructive patch anyway, in which I try to factor out the subtle decoding algorithm for co_lnotabs into an easy-to-use generator. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470 From noreply at sourceforge.net Thu Oct 16 09:16:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 09:16:35 2003 Subject: [Python-bugs-list] [ python-Bugs-811294 ] dis.disassemble_string() broken Message-ID: Bugs item #811294, was opened at 2003-09-23 17:23 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: dis.disassemble_string() broken Initial Comment: dis.disassemble_string(), called by dis.dis("some-bytecode-string"), still relies on the dead SET_LINENO opcode. I'll propose a patch for this at some later time. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2003-10-16 13:16 Message: Logged In: YES user_id=4771 Do we want findlinestarts() to be added to the public interface of dis? I think it is a generally useful tool (e.g. it could be used in trace.py too, though I don't understand trace.py well enough to know if the easy patch does exactly what is expected). I can write a doc patch if the answer is yes. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-16 12:55 Message: Logged In: YES user_id=6656 I think I trust Armin on stuff like this ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-09-26 11:07 Message: Logged In: YES user_id=4771 Here is a patch with a separate generator function that enumerates all (offset, lineno) pairs, as they where in the compiler before they got obfuscated into lnotab. For simplicity, disassemble() just turns them into a dict, so it didn't really have to be a generator at all, but it is just nicer this way. Maybe pdb could use it too. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-09-26 10:20 Message: Logged In: YES user_id=4771 ah well. I didn't realize that disassemble_string() never tried to *display* line numbers. It only detects SET_LINENO so that it can write a nice blank line before it. Attached a patch that removes this behavior (no longer possible in a function that doesn't have access to a co_lnotab). I'll submit another more constructive patch anyway, in which I try to factor out the subtle decoding algorithm for co_lnotabs into an easy-to-use generator. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470 From noreply at sourceforge.net Thu Oct 16 09:17:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 09:18:10 2003 Subject: [Python-bugs-list] [ python-Bugs-779976 ] docs missing 'trace' module Message-ID: Bugs item #779976, was opened at 2003-07-30 03:05 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779976&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Jeremy Hylton (jhylton) Summary: docs missing 'trace' module Initial Comment: The 'trace' module is new in Python 2.3. There is no mention of it in the module listing at http://www.python.org/ doc/2.3/modindex.html nor is it documented in the "undocumented modules" chapter at http://www.python.org/ doc/2.3/lib/undoc.html . (You would think as one of the coauthors for that module that I could be of help, but it's been about 4 years since I looked at it. :) ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-16 14:17 Message: Logged In: YES user_id=6656 Armin and I were talking about factoring out the co_lnotab-frobbing code and were being hampered by not knowing what the code was trying to do... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-09 22:00 Message: Logged In: YES user_id=3066 Jeremy made this a module, so he's volunteered to write the LaTeX docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779976&group_id=5470 From noreply at sourceforge.net Thu Oct 16 10:27:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 10:27:46 2003 Subject: [Python-bugs-list] [ python-Bugs-824854 ] dict.__init__ doesn't call subclass's __setitem__. Message-ID: Bugs item #824854, was opened at 2003-10-16 10: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=824854&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: dict.__init__ doesn't call subclass's __setitem__. Initial Comment: The easiest way to describe this is with the code I was using that uncovered this bug: class TwoWayDictionary(dict): __slots__ = () def __setitem__(self, key, value): dict.__setitem__(self, key, value) dict.__setitem__(self, value, key) I suspected this bug might happen, so I wrote this test: class TwoWayDictionaryTestCase(unittest.TestCase): def testInit(self): d = TwoWayDictionary(foo='bar') self.failUnless('foo' in d) self.failUnless('bar' in d) Basically, dict.__init__ is calling dict.__setitem__ even in subclasses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824854&group_id=5470 From noreply at sourceforge.net Thu Oct 16 10:33:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 10:33:29 2003 Subject: [Python-bugs-list] [ python-Bugs-824854 ] dict.__init__ doesn't call subclass's __setitem__. Message-ID: Bugs item #824854, was opened at 2003-10-16 15:27 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824854&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: dict.__init__ doesn't call subclass's __setitem__. Initial Comment: The easiest way to describe this is with the code I was using that uncovered this bug: class TwoWayDictionary(dict): __slots__ = () def __setitem__(self, key, value): dict.__setitem__(self, key, value) dict.__setitem__(self, value, key) I suspected this bug might happen, so I wrote this test: class TwoWayDictionaryTestCase(unittest.TestCase): def testInit(self): d = TwoWayDictionary(foo='bar') self.failUnless('foo' in d) self.failUnless('bar' in d) Basically, dict.__init__ is calling dict.__setitem__ even in subclasses. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-16 15:33 Message: Logged In: YES user_id=6656 .update() won't call TwoWayDictionary.__setitem__ either. Ditto .setdefault. You'll see similar behaviour for lists too. AFAIK, nowhere do the Python docs promise that the dictionary implementation is defined in terms of certain "primitive methods". You may think this a bug, but it's a whole lotta work to "fix" it. FWIW, you might be happier using UserDict.DictMixin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824854&group_id=5470 From noreply at sourceforge.net Thu Oct 16 10:41:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 10:41:47 2003 Subject: [Python-bugs-list] [ python-Bugs-824854 ] dict.__init__ doesn't call subclass's __setitem__. Message-ID: Bugs item #824854, was opened at 2003-10-16 10:27 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824854&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: dict.__init__ doesn't call subclass's __setitem__. Initial Comment: The easiest way to describe this is with the code I was using that uncovered this bug: class TwoWayDictionary(dict): __slots__ = () def __setitem__(self, key, value): dict.__setitem__(self, key, value) dict.__setitem__(self, value, key) I suspected this bug might happen, so I wrote this test: class TwoWayDictionaryTestCase(unittest.TestCase): def testInit(self): d = TwoWayDictionary(foo='bar') self.failUnless('foo' in d) self.failUnless('bar' in d) Basically, dict.__init__ is calling dict.__setitem__ even in subclasses. ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-16 10:41 Message: Logged In: YES user_id=99508 If someone went to the trouble to be able to define what "kermel methods" are used in the dict/list/whatever else implementations, would it even be accepted, or would it be considered too useless/slow/etc. to be bothered with? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-16 10:33 Message: Logged In: YES user_id=6656 .update() won't call TwoWayDictionary.__setitem__ either. Ditto .setdefault. You'll see similar behaviour for lists too. AFAIK, nowhere do the Python docs promise that the dictionary implementation is defined in terms of certain "primitive methods". You may think this a bug, but it's a whole lotta work to "fix" it. FWIW, you might be happier using UserDict.DictMixin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824854&group_id=5470 From noreply at sourceforge.net Thu Oct 16 10:50:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 10:50:46 2003 Subject: [Python-bugs-list] [ python-Bugs-824854 ] dict.__init__ doesn't call subclass's __setitem__. Message-ID: Bugs item #824854, was opened at 2003-10-16 15:27 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824854&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) >Assigned to: Guido van Rossum (gvanrossum) Summary: dict.__init__ doesn't call subclass's __setitem__. Initial Comment: The easiest way to describe this is with the code I was using that uncovered this bug: class TwoWayDictionary(dict): __slots__ = () def __setitem__(self, key, value): dict.__setitem__(self, key, value) dict.__setitem__(self, value, key) I suspected this bug might happen, so I wrote this test: class TwoWayDictionaryTestCase(unittest.TestCase): def testInit(self): d = TwoWayDictionary(foo='bar') self.failUnless('foo' in d) self.failUnless('bar' in d) Basically, dict.__init__ is calling dict.__setitem__ even in subclasses. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-16 15:50 Message: Logged In: YES user_id=6656 I honestly don't know. I slightly doubt it. It would probably be PEP material. I wonder what Guido thinks... ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-16 15:41 Message: Logged In: YES user_id=99508 If someone went to the trouble to be able to define what "kermel methods" are used in the dict/list/whatever else implementations, would it even be accepted, or would it be considered too useless/slow/etc. to be bothered with? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-16 15:33 Message: Logged In: YES user_id=6656 .update() won't call TwoWayDictionary.__setitem__ either. Ditto .setdefault. You'll see similar behaviour for lists too. AFAIK, nowhere do the Python docs promise that the dictionary implementation is defined in terms of certain "primitive methods". You may think this a bug, but it's a whole lotta work to "fix" it. FWIW, you might be happier using UserDict.DictMixin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824854&group_id=5470 From noreply at sourceforge.net Thu Oct 16 12:37:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 12:37:37 2003 Subject: [Python-bugs-list] [ python-Bugs-824947 ] strip on chr(0x1f) different with unicode Message-ID: Bugs item #824947, was opened at 2003-10-16 12: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=824947&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas B Hickey (thomasbhickey) Assigned to: M.-A. Lemburg (lemburg) Summary: strip on chr(0x1f) different with unicode Initial Comment: chr(0x1f) gets stripped from Unicode strings, but not from regular strings. I don't believe either should strip it. Python 2.3.1 (#47, Sep 23 2003, 23:47:32) [MSC v.1200 32 bit (Intel)] on win32 >>> sd = chr(0x1f) >>> sd.strip() '\x1f' >>> unicode(sd).strip() u'' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824947&group_id=5470 From noreply at sourceforge.net Thu Oct 16 12:55:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 12:56:01 2003 Subject: [Python-bugs-list] [ python-Bugs-824756 ] IDLE fails to start on Win2000 Message-ID: Bugs item #824756, was opened at 2003-10-16 13:51 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE fails to start on Win2000 Initial Comment: The new python-2.3.2-1.exe has not fixed the IDLE problem. I have two Windows 2000 machines (not running firewalls) on which IDLE does not start. Python itself works perfectly. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-10-16 18:55 Message: Logged In: YES user_id=11105 Can you provide some more details, please? Did you install Python in a directory containing spaces or not? Do you get a traceback if you try to start IDLE from the command line with python.exe instead of python2.exe: open a DOS box aka command prompt, and enter something like C:\Python23\python.exe "C:\Python23\Lib\idlelib\idle.pyw" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 From noreply at sourceforge.net Thu Oct 16 13:11:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 13:11:54 2003 Subject: [Python-bugs-list] [ python-Bugs-824756 ] IDLE fails to start on Win2000 Message-ID: Bugs item #824756, was opened at 2003-10-16 11:51 Message generated for change (Comment added) made by kbriggs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE fails to start on Win2000 Initial Comment: The new python-2.3.2-1.exe has not fixed the IDLE problem. I have two Windows 2000 machines (not running firewalls) on which IDLE does not start. Python itself works perfectly. ---------------------------------------------------------------------- >Comment By: Keith Briggs (kbriggs) Date: 2003-10-16 17:11 Message: Logged In: YES user_id=888261 There are no spaces in the path. d:\Python23\python.exe "d:\Python23\Lib\idlelib\idle.pyw" gives... Traceback (most recent call last): File "d:\Python23\Lib\idlelib\idle.pyw", line 4, in ? main() File "D:\Python23\lib\idlelib\PyShell.py", line 1269, in main root = Tk(className="Idle") File "D:\Python23\lib\lib-tk\Tkinter.py", line 1564, in __init__ self.tk = _tkinter.create(screenName, baseName, className) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {d:\ruby\tcl\lib\tcl8.3} {d:\ruby\tcl\lib\tcl8.3} d:/ruby/tcl/lib/tcl8.4 D:/Python23/lib/tcl8.4 D:/lib/tcl8.4 D:/library d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 16:55 Message: Logged In: YES user_id=11105 Can you provide some more details, please? Did you install Python in a directory containing spaces or not? Do you get a traceback if you try to start IDLE from the command line with python.exe instead of python2.exe: open a DOS box aka command prompt, and enter something like C:\Python23\python.exe "C:\Python23\Lib\idlelib\idle.pyw" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 From noreply at sourceforge.net Thu Oct 16 13:40:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 13:40:21 2003 Subject: [Python-bugs-list] [ python-Bugs-824977 ] Memory error on AIX in email.Utils._qdecode Message-ID: Bugs item #824977, was opened at 2003-10-16 13: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=824977&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: Memory error on AIX in email.Utils._qdecode Initial Comment: The following scriptlet works correctly on RedHat python2-2.2.3, but gets a MemoryError on AIX python-2.2.3. This is the only anomoly for AIX python I have seen. import email fp = open('analfail') msg = email.message_from_file(fp) for part in msg.walk(): if part.get_main_type() == 'text': txt = part.get_payload(decode=True) #del msg["content-transfer-encoding"] msg.set_payload(txt) fp.close() print msg.as_string() It doesn't matter whether the 'del' is there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 From noreply at sourceforge.net Thu Oct 16 13:43:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 13:43:27 2003 Subject: [Python-bugs-list] [ python-Bugs-824977 ] Memory error on AIX in email.Utils._qdecode Message-ID: Bugs item #824977, was opened at 2003-10-16 13:40 Message generated for change (Comment added) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: Memory error on AIX in email.Utils._qdecode Initial Comment: The following scriptlet works correctly on RedHat python2-2.2.3, but gets a MemoryError on AIX python-2.2.3. This is the only anomoly for AIX python I have seen. import email fp = open('analfail') msg = email.message_from_file(fp) for part in msg.walk(): if part.get_main_type() == 'text': txt = part.get_payload(decode=True) #del msg["content-transfer-encoding"] msg.set_payload(txt) fp.close() print msg.as_string() It doesn't matter whether the 'del' is there. ---------------------------------------------------------------------- >Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:43 Message: Logged In: YES user_id=142072 I forgot to include the traceback. $ python t.py Traceback (most recent call last): File "t.py", line 8, in ? txt = part.get_payload(decode=True) File "/usr/local/lib/python2.2/email/Message.py", line 197, in get_payload return Utils._qdecode(payload) File "/usr/local/lib/python2.2/quopri.py", line 161, in decodestring return a2b_qp(s, header = header) MemoryError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 From noreply at sourceforge.net Thu Oct 16 13:46:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 13:47:00 2003 Subject: [Python-bugs-list] [ python-Bugs-824756 ] IDLE fails to start on Win2000 Message-ID: Bugs item #824756, was opened at 2003-10-16 07:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE fails to start on Win2000 Initial Comment: The new python-2.3.2-1.exe has not fixed the IDLE problem. I have two Windows 2000 machines (not running firewalls) on which IDLE does not start. Python itself works perfectly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-16 13:46 Message: Logged In: YES user_id=31435 You installed Ruby. The Ruby installer is anti-social in the way it sets up Tcl/Tk. Look in your environment for envars starting with TCL and TK. The Ruby installer sets those, which forces every program trying to use Tcl or Tk to use Ruby's version of Tcl and Tk. There's nothing Python can do about that. Get rid of the envars and Python will run fine. ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2003-10-16 13:11 Message: Logged In: YES user_id=888261 There are no spaces in the path. d:\Python23\python.exe "d:\Python23\Lib\idlelib\idle.pyw" gives... Traceback (most recent call last): File "d:\Python23\Lib\idlelib\idle.pyw", line 4, in ? main() File "D:\Python23\lib\idlelib\PyShell.py", line 1269, in main root = Tk(className="Idle") File "D:\Python23\lib\lib-tk\Tkinter.py", line 1564, in __init__ self.tk = _tkinter.create(screenName, baseName, className) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {d:\ruby\tcl\lib\tcl8.3} {d:\ruby\tcl\lib\tcl8.3} d:/ruby/tcl/lib/tcl8.4 D:/Python23/lib/tcl8.4 D:/lib/tcl8.4 D:/library d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 12:55 Message: Logged In: YES user_id=11105 Can you provide some more details, please? Did you install Python in a directory containing spaces or not? Do you get a traceback if you try to start IDLE from the command line with python.exe instead of python2.exe: open a DOS box aka command prompt, and enter something like C:\Python23\python.exe "C:\Python23\Lib\idlelib\idle.pyw" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 From noreply at sourceforge.net Thu Oct 16 13:47:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 13:47:52 2003 Subject: [Python-bugs-list] [ python-Bugs-824977 ] Memory error on AIX in email.Utils._qdecode Message-ID: Bugs item #824977, was opened at 2003-10-16 13:40 Message generated for change (Comment added) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 >Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Nobody/Anonymous (nobody) Summary: Memory error on AIX in email.Utils._qdecode Initial Comment: The following scriptlet works correctly on RedHat python2-2.2.3, but gets a MemoryError on AIX python-2.2.3. This is the only anomoly for AIX python I have seen. import email fp = open('analfail') msg = email.message_from_file(fp) for part in msg.walk(): if part.get_main_type() == 'text': txt = part.get_payload(decode=True) #del msg["content-transfer-encoding"] msg.set_payload(txt) fp.close() print msg.as_string() It doesn't matter whether the 'del' is there. ---------------------------------------------------------------------- >Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:47 Message: Logged In: YES user_id=142072 It looks like the problem is with a2b_qp in the binascii extension module. So I am changing the Category. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:43 Message: Logged In: YES user_id=142072 I forgot to include the traceback. $ python t.py Traceback (most recent call last): File "t.py", line 8, in ? txt = part.get_payload(decode=True) File "/usr/local/lib/python2.2/email/Message.py", line 197, in get_payload return Utils._qdecode(payload) File "/usr/local/lib/python2.2/quopri.py", line 161, in decodestring return a2b_qp(s, header = header) MemoryError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 From noreply at sourceforge.net Thu Oct 16 14:28:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 14:28:31 2003 Subject: [Python-bugs-list] [ python-Bugs-824977 ] Memory error on AIX in email.Utils._qdecode Message-ID: Bugs item #824977, was opened at 2003-10-16 13:40 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory error on AIX in email.Utils._qdecode Initial Comment: The following scriptlet works correctly on RedHat python2-2.2.3, but gets a MemoryError on AIX python-2.2.3. This is the only anomoly for AIX python I have seen. import email fp = open('analfail') msg = email.message_from_file(fp) for part in msg.walk(): if part.get_main_type() == 'text': txt = part.get_payload(decode=True) #del msg["content-transfer-encoding"] msg.set_payload(txt) fp.close() print msg.as_string() It doesn't matter whether the 'del' is there. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:47 Message: Logged In: YES user_id=142072 It looks like the problem is with a2b_qp in the binascii extension module. So I am changing the Category. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:43 Message: Logged In: YES user_id=142072 I forgot to include the traceback. $ python t.py Traceback (most recent call last): File "t.py", line 8, in ? txt = part.get_payload(decode=True) File "/usr/local/lib/python2.2/email/Message.py", line 197, in get_payload return Utils._qdecode(payload) File "/usr/local/lib/python2.2/quopri.py", line 161, in decodestring return a2b_qp(s, header = header) MemoryError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 From noreply at sourceforge.net Thu Oct 16 14:50:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 14:50:20 2003 Subject: [Python-bugs-list] [ python-Bugs-824756 ] IDLE fails to start on Win2000 Message-ID: Bugs item #824756, was opened at 2003-10-16 13:51 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE fails to start on Win2000 Initial Comment: The new python-2.3.2-1.exe has not fixed the IDLE problem. I have two Windows 2000 machines (not running firewalls) on which IDLE does not start. Python itself works perfectly. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-10-16 20:50 Message: Logged In: YES user_id=11105 Hm, python.exe and pythonw.exe *could* set it's own envvars. Maybe. Or not. But anyway, shouldn't pythonw.exe be able to display tracebacks? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 19:46 Message: Logged In: YES user_id=31435 You installed Ruby. The Ruby installer is anti-social in the way it sets up Tcl/Tk. Look in your environment for envars starting with TCL and TK. The Ruby installer sets those, which forces every program trying to use Tcl or Tk to use Ruby's version of Tcl and Tk. There's nothing Python can do about that. Get rid of the envars and Python will run fine. ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2003-10-16 19:11 Message: Logged In: YES user_id=888261 There are no spaces in the path. d:\Python23\python.exe "d:\Python23\Lib\idlelib\idle.pyw" gives... Traceback (most recent call last): File "d:\Python23\Lib\idlelib\idle.pyw", line 4, in ? main() File "D:\Python23\lib\idlelib\PyShell.py", line 1269, in main root = Tk(className="Idle") File "D:\Python23\lib\lib-tk\Tkinter.py", line 1564, in __init__ self.tk = _tkinter.create(screenName, baseName, className) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {d:\ruby\tcl\lib\tcl8.3} {d:\ruby\tcl\lib\tcl8.3} d:/ruby/tcl/lib/tcl8.4 D:/Python23/lib/tcl8.4 D:/lib/tcl8.4 D:/library d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 18:55 Message: Logged In: YES user_id=11105 Can you provide some more details, please? Did you install Python in a directory containing spaces or not? Do you get a traceback if you try to start IDLE from the command line with python.exe instead of python2.exe: open a DOS box aka command prompt, and enter something like C:\Python23\python.exe "C:\Python23\Lib\idlelib\idle.pyw" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 From noreply at sourceforge.net Thu Oct 16 15:16:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 15:16:31 2003 Subject: [Python-bugs-list] [ python-Bugs-824016 ] MSVCRT.DLL screws up the system Message-ID: Bugs item #824016, was opened at 2003-10-15 12:05 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824016&group_id=5470 Category: Windows Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Petter Holmstr?m (pholmstrom) Assigned to: Thomas Heller (theller) Summary: MSVCRT.DLL screws up the system Initial Comment: This applies to the Windows version of Python 2.3.2. When a friend of mine installed Python onto his computer (running Windows NT 4) the entire system got screwed up and he had to reinstall the operating system and all applications. The errors reported all had to do with unresolved symbols in the MSVCRT.DLL -file. Uninstalling Python did not help. I also encountered a similar problem. After installing Python on a Windows NT 4 machine Quattro Pro 9 would not start, complaining about unresolved symbols in the MSVCRT.DLL -file. When I uninstalled Python and rolled back the changes QP started just fine. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-10-16 21:16 Message: Logged In: YES user_id=11105 I'm really sorry for this - there were wrong MS dlls included in the installer for Python 2.3.2. A new installer has been created, and can be downloaded in the usual place. The filename has changed to Python-2.3.2-1.exe. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824016&group_id=5470 From noreply at sourceforge.net Thu Oct 16 15:17:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 15:17:56 2003 Subject: [Python-bugs-list] [ python-Bugs-824756 ] IDLE fails to start on Win2000 Message-ID: Bugs item #824756, was opened at 2003-10-16 07:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE fails to start on Win2000 Initial Comment: The new python-2.3.2-1.exe has not fixed the IDLE problem. I have two Windows 2000 machines (not running firewalls) on which IDLE does not start. Python itself works perfectly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-16 15:17 Message: Logged In: YES user_id=31435 If Python set Tcl/Tk envars, it would be as anti-social as Ruby. If Ruby managed Tcl/Tk the way Python managed it, everyone would co-exist peacefully. pythonw has nowhere to display a traceback -- it doesn't have a console (and not having a console is the point of pythonw -- that one's not shallow ). "It would be nice" if it pythonw opened a message window to display tracebacks. As is, programs that try to write to stdout or stderr under pythonw can even crash (Windows doesn't complain if you try to write to stdout or stderr then, but they're hooked up to something that crashes on some systems if you write "too much"). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 14:50 Message: Logged In: YES user_id=11105 Hm, python.exe and pythonw.exe *could* set it's own envvars. Maybe. Or not. But anyway, shouldn't pythonw.exe be able to display tracebacks? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 13:46 Message: Logged In: YES user_id=31435 You installed Ruby. The Ruby installer is anti-social in the way it sets up Tcl/Tk. Look in your environment for envars starting with TCL and TK. The Ruby installer sets those, which forces every program trying to use Tcl or Tk to use Ruby's version of Tcl and Tk. There's nothing Python can do about that. Get rid of the envars and Python will run fine. ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2003-10-16 13:11 Message: Logged In: YES user_id=888261 There are no spaces in the path. d:\Python23\python.exe "d:\Python23\Lib\idlelib\idle.pyw" gives... Traceback (most recent call last): File "d:\Python23\Lib\idlelib\idle.pyw", line 4, in ? main() File "D:\Python23\lib\idlelib\PyShell.py", line 1269, in main root = Tk(className="Idle") File "D:\Python23\lib\lib-tk\Tkinter.py", line 1564, in __init__ self.tk = _tkinter.create(screenName, baseName, className) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {d:\ruby\tcl\lib\tcl8.3} {d:\ruby\tcl\lib\tcl8.3} d:/ruby/tcl/lib/tcl8.4 D:/Python23/lib/tcl8.4 D:/lib/tcl8.4 D:/library d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 12:55 Message: Logged In: YES user_id=11105 Can you provide some more details, please? Did you install Python in a directory containing spaces or not? Do you get a traceback if you try to start IDLE from the command line with python.exe instead of python2.exe: open a DOS box aka command prompt, and enter something like C:\Python23\python.exe "C:\Python23\Lib\idlelib\idle.pyw" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 From noreply at sourceforge.net Thu Oct 16 15:17:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 15:18:00 2003 Subject: [Python-bugs-list] [ python-Bugs-818029 ] installer wakes up Windows File Protection Message-ID: Bugs item #818029, was opened at 2003-10-05 10:49 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Pete (thegoldenear) Assigned to: Thomas Heller (theller) Summary: installer wakes up Windows File Protection Initial Comment: installing Python 2.3.2 on Windows 2000 SP4 induced the Windows File Protection, presumably bcos an existing system file had been replaced by an older version ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-10-16 21:17 Message: Logged In: YES user_id=11105 Python-2.3.2-1.exe should have fixed this problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-15 23:13 Message: Logged In: YES user_id=21627 The answer for the "why" probably is that Win95, out of the box, does not include msvcrt.dll (only msvcrt20.dll and msvcrt40.dll). Many users of Win95 probably have msvcrt.dll because they have installed MS Office or some other software including it. Any kind of patch to Win95 (including Win95B) installs msvcrt.dll also. To solve this problem, I would suggest to discontinue support for Win95 in Python 2.4. But then, I also suggest to use VC7.1 for Python2.4, which brings up the issue of distributing MSVCR71.dll... ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-14 20:17 Message: Logged In: YES user_id=11105 The clearest description *how* to ship these dlls I did find here: http://www.jrsoftware.org/ishowto.phtml?a=vc Of course, this doesn't answer the question *whether* they should be distributed at all. And I do know that on a clean Win95 system the MFC dlls were not present, unless write (aka wordpad) was installed. Don't remember anymore if this also applied to msvcrt.dll. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-14 20:07 Message: Logged In: YES user_id=31435 While we're at it, I'd like to question whether we should be shipping MS dlls at all. I'd *like* to question it, but have never known how to : I don't know that it's necessary to ship them, especially since we don't support DOS directly anymore. OTOH, I don't know that no box out there needs them either. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-14 19:29 Message: Logged In: YES user_id=11105 It seems I did include msvcrt.dll and msvcirt.dll from my system directory, but probably the files from VC6 SP5 should be included. IMO msvcirt.dll is not used by Python, but msvcirt.dll uses msvcrt.dll, so it makes sense to include both of these files in the installer. Here are the version numbers I found in the various installers: Python-2.3.exe: msvcrt.dll - 6.1.8637.0, msvcirt.dll - 6.1.8168.0 Python-2.3.2.exe: msvcrt.dll - 7.0.2600.1106, msvcirt.dll - 7.0.2600.0 vcredist.exe: msvcrt.dll - 6.0.8797.0, msvcirt.dll - 6.0.8168.0 The vcredist.exe is from the VC6 SP5 CD. I will include the latter files in the next installer (2.3.3), and hopefully everything will be ok then. Assigned back to myself. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-06 17:50 Message: Logged In: YES user_id=31435 msvcirt.dll was in the installer when I inherited it from Guido. He probably inherited it from Mark (Hammond). If Mark can't remember why it's there either, we should check all the .pyd (not just python23.dll) for references to it. Assigned to Mark. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-06 17:38 Message: Logged In: YES user_id=11105 I *can* reproduce it - look into the event viewer, category 'System': File replacement was attempted on the protected system file d:\winnt\system32\msvcirt.dll... The windows installer tries (in my case) to replace the version 6.1.8637.0 with 7.0.2600.0. Looking at python23.dll's dependencies with Dependency Walker, it seems that msvcirt.dll isn't required by Python at all, so the solution would be simple: leave msvcirt.dll out of the installer. Why is it in the installer at all? Tim? ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-10-05 23:21 Message: Logged In: YES user_id=699438 I couldn't reproduce this on a stock install of W2K SP 4. If you're in a position to do so (you'll need the physical CD media), could you rebuild your DLL cache? From the command-line "sfc /purgecache && sfc /scannow" should do this. After that, try to install python2.3.2 and see if sfc kicks in again. If you can't do that, you might want to see if the file python23.dll somehow manually ended up in the %windir% \system32\dllcache directory. As far as I know, thats the only file that should be getting shoved into an area the sfc cares about. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-05 20:12 Message: Logged In: YES user_id=31435 Changed category to Windows and assigned to Thomas Heller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818029&group_id=5470 From noreply at sourceforge.net Thu Oct 16 15:32:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 15:32:38 2003 Subject: [Python-bugs-list] [ python-Bugs-824756 ] IDLE fails to start on Win2000 Message-ID: Bugs item #824756, was opened at 2003-10-16 13:51 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE fails to start on Win2000 Initial Comment: The new python-2.3.2-1.exe has not fixed the IDLE problem. I have two Windows 2000 machines (not running firewalls) on which IDLE does not start. Python itself works perfectly. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-10-16 21:32 Message: Logged In: YES user_id=11105 I didn't mean that the Python installer sets these envvars systemwide, I meant that Python should know where a usable Tcl/Tk is installed. How this is communicated to Tkinter I don't know. But, worse, I find it a shame that IDLE cannot start because of this (or another problem) without pythonw trying to give the poor user *any* hint about what's wrong. Why isn't it the default for pythonw to redirect stderr into a MessageBox? I suggest to close *this* bug with either "won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 21:17 Message: Logged In: YES user_id=31435 If Python set Tcl/Tk envars, it would be as anti-social as Ruby. If Ruby managed Tcl/Tk the way Python managed it, everyone would co-exist peacefully. pythonw has nowhere to display a traceback -- it doesn't have a console (and not having a console is the point of pythonw -- that one's not shallow ). "It would be nice" if it pythonw opened a message window to display tracebacks. As is, programs that try to write to stdout or stderr under pythonw can even crash (Windows doesn't complain if you try to write to stdout or stderr then, but they're hooked up to something that crashes on some systems if you write "too much"). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 20:50 Message: Logged In: YES user_id=11105 Hm, python.exe and pythonw.exe *could* set it's own envvars. Maybe. Or not. But anyway, shouldn't pythonw.exe be able to display tracebacks? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 19:46 Message: Logged In: YES user_id=31435 You installed Ruby. The Ruby installer is anti-social in the way it sets up Tcl/Tk. Look in your environment for envars starting with TCL and TK. The Ruby installer sets those, which forces every program trying to use Tcl or Tk to use Ruby's version of Tcl and Tk. There's nothing Python can do about that. Get rid of the envars and Python will run fine. ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2003-10-16 19:11 Message: Logged In: YES user_id=888261 There are no spaces in the path. d:\Python23\python.exe "d:\Python23\Lib\idlelib\idle.pyw" gives... Traceback (most recent call last): File "d:\Python23\Lib\idlelib\idle.pyw", line 4, in ? main() File "D:\Python23\lib\idlelib\PyShell.py", line 1269, in main root = Tk(className="Idle") File "D:\Python23\lib\lib-tk\Tkinter.py", line 1564, in __init__ self.tk = _tkinter.create(screenName, baseName, className) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {d:\ruby\tcl\lib\tcl8.3} {d:\ruby\tcl\lib\tcl8.3} d:/ruby/tcl/lib/tcl8.4 D:/Python23/lib/tcl8.4 D:/lib/tcl8.4 D:/library d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 18:55 Message: Logged In: YES user_id=11105 Can you provide some more details, please? Did you install Python in a directory containing spaces or not? Do you get a traceback if you try to start IDLE from the command line with python.exe instead of python2.exe: open a DOS box aka command prompt, and enter something like C:\Python23\python.exe "C:\Python23\Lib\idlelib\idle.pyw" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 From noreply at sourceforge.net Thu Oct 16 15:42:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 15:43:15 2003 Subject: [Python-bugs-list] [ python-Bugs-823380 ] distutils: dir[ectory]_created Message-ID: Bugs item #823380, was opened at 2003-10-14 14:00 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823380&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Lukasz Pankowski (lupan) Assigned to: Thomas Heller (theller) Summary: distutils: dir[ectory]_created Initial Comment: In docutils documentation in section `The Postinstallation script' (python/dist/src/Doc/dist/dist.tex) mensions function dir_created, while it should be directory_created (python/dist/src/PC/bdist_wininst/install.c). Grepping the CVS tree shows the inconsistency: lupan@psi:[~/local/python]$ find -type f -print0 | xargs -0 grep [ry]_created ./dist/src/Doc/dist/dist.tex:dir_created(pathname) ./dist/src/PC/bdist_wininst/install.c: {"directory_created", DirectoryCreated, METH_VARARGS, NULL}, ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-10-16 21:42 Message: Logged In: YES user_id=11105 Fixed in dist.tex revision 1.59 and 1.56.8.3. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823380&group_id=5470 From noreply at sourceforge.net Thu Oct 16 16:00:17 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 16:00:46 2003 Subject: [Python-bugs-list] [ python-Bugs-824977 ] Memory error on AIX in email.Utils._qdecode Message-ID: Bugs item #824977, was opened at 2003-10-16 13:40 Message generated for change (Comment added) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) >Assigned to: Nobody/Anonymous (nobody) Summary: Memory error on AIX in email.Utils._qdecode Initial Comment: The following scriptlet works correctly on RedHat python2-2.2.3, but gets a MemoryError on AIX python-2.2.3. This is the only anomoly for AIX python I have seen. import email fp = open('analfail') msg = email.message_from_file(fp) for part in msg.walk(): if part.get_main_type() == 'text': txt = part.get_payload(decode=True) #del msg["content-transfer-encoding"] msg.set_payload(txt) fp.close() print msg.as_string() It doesn't matter whether the 'del' is there. ---------------------------------------------------------------------- >Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 16:00 Message: Logged In: YES user_id=142072 Fixed binascii as follows: --- ./Modules/binascii.c.bms Mon Mar 17 06:34:43 2003 +++ ./Modules/binascii.c Thu Oct 16 15:55:34 2003 @@ -1036,7 +1036,7 @@ /* We allocate the output same size as input, this is overkill */ odata = (unsigned char *) calloc(1, datalen); - if (odata == NULL) { + if (odata == NULL && datalen > 0) { PyErr_NoMemory(); return NULL; } This bug will manifest not just on AIX, but any system which returns NULL from malloc or calloc when allocated size is 0. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:47 Message: Logged In: YES user_id=142072 It looks like the problem is with a2b_qp in the binascii extension module. So I am changing the Category. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:43 Message: Logged In: YES user_id=142072 I forgot to include the traceback. $ python t.py Traceback (most recent call last): File "t.py", line 8, in ? txt = part.get_payload(decode=True) File "/usr/local/lib/python2.2/email/Message.py", line 197, in get_payload return Utils._qdecode(payload) File "/usr/local/lib/python2.2/quopri.py", line 161, in decodestring return a2b_qp(s, header = header) MemoryError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 From noreply at sourceforge.net Thu Oct 16 16:01:25 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 16:01:29 2003 Subject: [Python-bugs-list] [ python-Bugs-824977 ] Memory error on AIX in email.Utils._qdecode Message-ID: Bugs item #824977, was opened at 2003-10-16 13:40 Message generated for change (Settings changed) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory error on AIX in email.Utils._qdecode Initial Comment: The following scriptlet works correctly on RedHat python2-2.2.3, but gets a MemoryError on AIX python-2.2.3. This is the only anomoly for AIX python I have seen. import email fp = open('analfail') msg = email.message_from_file(fp) for part in msg.walk(): if part.get_main_type() == 'text': txt = part.get_payload(decode=True) #del msg["content-transfer-encoding"] msg.set_payload(txt) fp.close() print msg.as_string() It doesn't matter whether the 'del' is there. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 16:00 Message: Logged In: YES user_id=142072 Fixed binascii as follows: --- ./Modules/binascii.c.bms Mon Mar 17 06:34:43 2003 +++ ./Modules/binascii.c Thu Oct 16 15:55:34 2003 @@ -1036,7 +1036,7 @@ /* We allocate the output same size as input, this is overkill */ odata = (unsigned char *) calloc(1, datalen); - if (odata == NULL) { + if (odata == NULL && datalen > 0) { PyErr_NoMemory(); return NULL; } This bug will manifest not just on AIX, but any system which returns NULL from malloc or calloc when allocated size is 0. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:47 Message: Logged In: YES user_id=142072 It looks like the problem is with a2b_qp in the binascii extension module. So I am changing the Category. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:43 Message: Logged In: YES user_id=142072 I forgot to include the traceback. $ python t.py Traceback (most recent call last): File "t.py", line 8, in ? txt = part.get_payload(decode=True) File "/usr/local/lib/python2.2/email/Message.py", line 197, in get_payload return Utils._qdecode(payload) File "/usr/local/lib/python2.2/quopri.py", line 161, in decodestring return a2b_qp(s, header = header) MemoryError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 From noreply at sourceforge.net Thu Oct 16 16:14:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 16:15:03 2003 Subject: [Python-bugs-list] [ python-Bugs-824977 ] Memory error on AIX in email.Utils._qdecode Message-ID: Bugs item #824977, was opened at 2003-10-16 13:40 Message generated for change (Comment added) made by customdesigned You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory error on AIX in email.Utils._qdecode Initial Comment: The following scriptlet works correctly on RedHat python2-2.2.3, but gets a MemoryError on AIX python-2.2.3. This is the only anomoly for AIX python I have seen. import email fp = open('analfail') msg = email.message_from_file(fp) for part in msg.walk(): if part.get_main_type() == 'text': txt = part.get_payload(decode=True) #del msg["content-transfer-encoding"] msg.set_payload(txt) fp.close() print msg.as_string() It doesn't matter whether the 'del' is there. ---------------------------------------------------------------------- >Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 16:14 Message: Logged In: YES user_id=142072 Might as well fix b2a_qp while we are at it: --- ./Modules/binascii.c.aix Mon Mar 17 06:34:43 2003 +++ ./Modules/binascii.c Thu Oct 16 16:08:25 2003 @@ -1036,7 +1036,7 @@ /* We allocate the output same size as input, this is overkill */ odata = (unsigned char *) calloc(1, datalen); - if (odata == NULL) { + if (odata == NULL && datalen > 0) { PyErr_NoMemory(); return NULL; } @@ -1206,7 +1206,7 @@ odata = (unsigned char *) calloc(1, odatalen); - if (odata == NULL) { + if (odata == NULL && odatalen > 0) { PyErr_NoMemory(); return NULL; } ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 16:00 Message: Logged In: YES user_id=142072 Fixed binascii as follows: --- ./Modules/binascii.c.bms Mon Mar 17 06:34:43 2003 +++ ./Modules/binascii.c Thu Oct 16 15:55:34 2003 @@ -1036,7 +1036,7 @@ /* We allocate the output same size as input, this is overkill */ odata = (unsigned char *) calloc(1, datalen); - if (odata == NULL) { + if (odata == NULL && datalen > 0) { PyErr_NoMemory(); return NULL; } This bug will manifest not just on AIX, but any system which returns NULL from malloc or calloc when allocated size is 0. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:47 Message: Logged In: YES user_id=142072 It looks like the problem is with a2b_qp in the binascii extension module. So I am changing the Category. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 13:43 Message: Logged In: YES user_id=142072 I forgot to include the traceback. $ python t.py Traceback (most recent call last): File "t.py", line 8, in ? txt = part.get_payload(decode=True) File "/usr/local/lib/python2.2/email/Message.py", line 197, in get_payload return Utils._qdecode(payload) File "/usr/local/lib/python2.2/quopri.py", line 161, in decodestring return a2b_qp(s, header = header) MemoryError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 From noreply at sourceforge.net Thu Oct 16 16:42:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 16:42:40 2003 Subject: [Python-bugs-list] [ python-Bugs-824756 ] IDLE fails to start on Win2000 Message-ID: Bugs item #824756, was opened at 2003-10-16 07:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE fails to start on Win2000 Initial Comment: The new python-2.3.2-1.exe has not fixed the IDLE problem. I have two Windows 2000 machines (not running firewalls) on which IDLE does not start. Python itself works perfectly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-16 16:42 Message: Logged In: YES user_id=31435 I prefer to keep the report open until the OP reports success or failure (or a week has gone by without hearing more). pythonw's woes wrt not reporting errors has been discussed several times before, but nobody has volunteered the work to "do something" about it. Good topic for python-dev -- it gets too much Linux-specific crud anyway . ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 15:32 Message: Logged In: YES user_id=11105 I didn't mean that the Python installer sets these envvars systemwide, I meant that Python should know where a usable Tcl/Tk is installed. How this is communicated to Tkinter I don't know. But, worse, I find it a shame that IDLE cannot start because of this (or another problem) without pythonw trying to give the poor user *any* hint about what's wrong. Why isn't it the default for pythonw to redirect stderr into a MessageBox? I suggest to close *this* bug with either "won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 15:17 Message: Logged In: YES user_id=31435 If Python set Tcl/Tk envars, it would be as anti-social as Ruby. If Ruby managed Tcl/Tk the way Python managed it, everyone would co-exist peacefully. pythonw has nowhere to display a traceback -- it doesn't have a console (and not having a console is the point of pythonw -- that one's not shallow ). "It would be nice" if it pythonw opened a message window to display tracebacks. As is, programs that try to write to stdout or stderr under pythonw can even crash (Windows doesn't complain if you try to write to stdout or stderr then, but they're hooked up to something that crashes on some systems if you write "too much"). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 14:50 Message: Logged In: YES user_id=11105 Hm, python.exe and pythonw.exe *could* set it's own envvars. Maybe. Or not. But anyway, shouldn't pythonw.exe be able to display tracebacks? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 13:46 Message: Logged In: YES user_id=31435 You installed Ruby. The Ruby installer is anti-social in the way it sets up Tcl/Tk. Look in your environment for envars starting with TCL and TK. The Ruby installer sets those, which forces every program trying to use Tcl or Tk to use Ruby's version of Tcl and Tk. There's nothing Python can do about that. Get rid of the envars and Python will run fine. ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2003-10-16 13:11 Message: Logged In: YES user_id=888261 There are no spaces in the path. d:\Python23\python.exe "d:\Python23\Lib\idlelib\idle.pyw" gives... Traceback (most recent call last): File "d:\Python23\Lib\idlelib\idle.pyw", line 4, in ? main() File "D:\Python23\lib\idlelib\PyShell.py", line 1269, in main root = Tk(className="Idle") File "D:\Python23\lib\lib-tk\Tkinter.py", line 1564, in __init__ self.tk = _tkinter.create(screenName, baseName, className) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {d:\ruby\tcl\lib\tcl8.3} {d:\ruby\tcl\lib\tcl8.3} d:/ruby/tcl/lib/tcl8.4 D:/Python23/lib/tcl8.4 D:/lib/tcl8.4 D:/library d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 12:55 Message: Logged In: YES user_id=11105 Can you provide some more details, please? Did you install Python in a directory containing spaces or not? Do you get a traceback if you try to start IDLE from the command line with python.exe instead of python2.exe: open a DOS box aka command prompt, and enter something like C:\Python23\python.exe "C:\Python23\Lib\idlelib\idle.pyw" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 From noreply at sourceforge.net Thu Oct 16 21:55:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 21:55:51 2003 Subject: [Python-bugs-list] [ python-Bugs-825247 ] Itertools imap and izip boundary cases Message-ID: Bugs item #825247, was opened at 2003-10-17 01:55 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=825247&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Dickinson (marketdickinson) Assigned to: Nobody/Anonymous (nobody) Summary: Itertools imap and izip boundary cases Initial Comment: It appears that itertools.imap cannot be applied to a function f of zero arguments: imap(f) raises a TypeError with the message "imap() must have at least two arguments". Is there a reason for this restriction? There's a logical and natural definition for imap(f), which fits with all the current documentation: it should be an iterator returning the sequence f(), f(), f(), .... Not only is this natural but it's also useful: for example, imap(random) is a handy way to write down an iterator that returns a succession of random floats in [0, 1). Is there a reason for treating functions with zero arguments differently from functions with one or more arguments? I'd also argue that the result of izip() is incorrect: if it's going to work according to the same rules as other calls of izip, it should return an infinite list of empty tuples; that is, it should be equivalent to repeat(()). As the docstring states, the .next() method should continue until one of the iterables is exhausted; with no iterables, this never happens, so a strict logical reading of this statement is that the .next() method of izip() should continue indefinitely. This definition of izip() also ensures that natural laws like imap(f, *args) = starmap(f, izip(*args)) don't break in the boundary case (at least, given my proposed definition of imap(f) above). (The above changes can be effected by simply removing 7 lines from the itertools.c source code.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825247&group_id=5470 From noreply at sourceforge.net Thu Oct 16 22:22:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 16 22:22:45 2003 Subject: [Python-bugs-list] [ python-Bugs-825247 ] Itertools imap and izip boundary cases Message-ID: Bugs item #825247, was opened at 2003-10-16 21:55 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825247&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Dickinson (marketdickinson) >Assigned to: Raymond Hettinger (rhettinger) Summary: Itertools imap and izip boundary cases Initial Comment: It appears that itertools.imap cannot be applied to a function f of zero arguments: imap(f) raises a TypeError with the message "imap() must have at least two arguments". Is there a reason for this restriction? There's a logical and natural definition for imap(f), which fits with all the current documentation: it should be an iterator returning the sequence f(), f(), f(), .... Not only is this natural but it's also useful: for example, imap(random) is a handy way to write down an iterator that returns a succession of random floats in [0, 1). Is there a reason for treating functions with zero arguments differently from functions with one or more arguments? I'd also argue that the result of izip() is incorrect: if it's going to work according to the same rules as other calls of izip, it should return an infinite list of empty tuples; that is, it should be equivalent to repeat(()). As the docstring states, the .next() method should continue until one of the iterables is exhausted; with no iterables, this never happens, so a strict logical reading of this statement is that the .next() method of izip() should continue indefinitely. This definition of izip() also ensures that natural laws like imap(f, *args) = starmap(f, izip(*args)) don't break in the boundary case (at least, given my proposed definition of imap(f) above). (The above changes can be effected by simply removing 7 lines from the itertools.c source code.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825247&group_id=5470 From noreply at sourceforge.net Fri Oct 17 00:40:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 00:41:07 2003 Subject: [Python-bugs-list] [ python-Bugs-825247 ] Itertools imap and izip boundary cases Message-ID: Bugs item #825247, was opened at 2003-10-16 20:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825247&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mark Dickinson (marketdickinson) Assigned to: Raymond Hettinger (rhettinger) Summary: Itertools imap and izip boundary cases Initial Comment: It appears that itertools.imap cannot be applied to a function f of zero arguments: imap(f) raises a TypeError with the message "imap() must have at least two arguments". Is there a reason for this restriction? There's a logical and natural definition for imap(f), which fits with all the current documentation: it should be an iterator returning the sequence f(), f(), f(), .... Not only is this natural but it's also useful: for example, imap(random) is a handy way to write down an iterator that returns a succession of random floats in [0, 1). Is there a reason for treating functions with zero arguments differently from functions with one or more arguments? I'd also argue that the result of izip() is incorrect: if it's going to work according to the same rules as other calls of izip, it should return an infinite list of empty tuples; that is, it should be equivalent to repeat(()). As the docstring states, the .next() method should continue until one of the iterables is exhausted; with no iterables, this never happens, so a strict logical reading of this statement is that the .next() method of izip() should continue indefinitely. This definition of izip() also ensures that natural laws like imap(f, *args) = starmap(f, izip(*args)) don't break in the boundary case (at least, given my proposed definition of imap(f) above). (The above changes can be effected by simply removing 7 lines from the itertools.c source code.) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-16 23:40 Message: Logged In: YES user_id=80475 These are not bugs. They were each thought about and rejected during the design process. At best they can be considered feature requests for use cases that can be already be satistified in other ways: * repeat(()) # gives an infinite list of tuples * starmap(random.random, repeat(())) # infinite series of random numbers FWIW, here is some of the rationale behind the current design. imap() was kept as parallel as possible with map() which also requires at least two arguments. The None fill-in feature of map() was specifically discarded so that infinite iterators could be freely mixed with finite iterators and yield a finite result. The design is to *not* trigger infinite iteration unless specifically requested. IMO, the absence of arguments is most likely a programmer error and should be flagged immediately. I did consider use cases like random() and ctime(). They are foremost among the rare infinite functions with meaningful outputs but no inputs. They were not common enough to warrant mucking-up imap() especially when the need is already met by starmap(func, repeat()) or iter(callable, impossibleSentinel). Note, there are many useful non-infinite functions with no arguments -- for these, use iter(callable, sentinel) In Py2.3.2 and beyond, izip() accepts zero arguments to keep it consistent with zip() which, in Py2.4, will return an empty list. The rationale for the change was to complete the boundary case for zip(*args) which is common definition for a matrix transpose or for unzipping. Like imap(), infinite iteration needs to be explicitly requested. izip() is for lockstep iteration; if you want a infinite series of empty tuples, use the tool designed for that need: repeat(()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825247&group_id=5470 From noreply at sourceforge.net Fri Oct 17 05:21:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 05:21:37 2003 Subject: [Python-bugs-list] [ python-Bugs-824756 ] IDLE fails to start on Win2000 Message-ID: Bugs item #824756, was opened at 2003-10-16 11:51 Message generated for change (Comment added) made by kbriggs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE fails to start on Win2000 Initial Comment: The new python-2.3.2-1.exe has not fixed the IDLE problem. I have two Windows 2000 machines (not running firewalls) on which IDLE does not start. Python itself works perfectly. ---------------------------------------------------------------------- >Comment By: Keith Briggs (kbriggs) Date: 2003-10-17 09:21 Message: Logged In: YES user_id=888261 Yes, removing TCL_LIBRARY set by ruby fixes the problem. Thanks for everybody's help. I am not a Windows person, otherwise I could have fixed this myself. We are told to trust auto-installers. Now I know not to. Back to linux for real work now... (But does this mean python and ruby cannot coexist on a Windows machine?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 20:42 Message: Logged In: YES user_id=31435 I prefer to keep the report open until the OP reports success or failure (or a week has gone by without hearing more). pythonw's woes wrt not reporting errors has been discussed several times before, but nobody has volunteered the work to "do something" about it. Good topic for python-dev -- it gets too much Linux-specific crud anyway . ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 19:32 Message: Logged In: YES user_id=11105 I didn't mean that the Python installer sets these envvars systemwide, I meant that Python should know where a usable Tcl/Tk is installed. How this is communicated to Tkinter I don't know. But, worse, I find it a shame that IDLE cannot start because of this (or another problem) without pythonw trying to give the poor user *any* hint about what's wrong. Why isn't it the default for pythonw to redirect stderr into a MessageBox? I suggest to close *this* bug with either "won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 19:17 Message: Logged In: YES user_id=31435 If Python set Tcl/Tk envars, it would be as anti-social as Ruby. If Ruby managed Tcl/Tk the way Python managed it, everyone would co-exist peacefully. pythonw has nowhere to display a traceback -- it doesn't have a console (and not having a console is the point of pythonw -- that one's not shallow ). "It would be nice" if it pythonw opened a message window to display tracebacks. As is, programs that try to write to stdout or stderr under pythonw can even crash (Windows doesn't complain if you try to write to stdout or stderr then, but they're hooked up to something that crashes on some systems if you write "too much"). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 18:50 Message: Logged In: YES user_id=11105 Hm, python.exe and pythonw.exe *could* set it's own envvars. Maybe. Or not. But anyway, shouldn't pythonw.exe be able to display tracebacks? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 17:46 Message: Logged In: YES user_id=31435 You installed Ruby. The Ruby installer is anti-social in the way it sets up Tcl/Tk. Look in your environment for envars starting with TCL and TK. The Ruby installer sets those, which forces every program trying to use Tcl or Tk to use Ruby's version of Tcl and Tk. There's nothing Python can do about that. Get rid of the envars and Python will run fine. ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2003-10-16 17:11 Message: Logged In: YES user_id=888261 There are no spaces in the path. d:\Python23\python.exe "d:\Python23\Lib\idlelib\idle.pyw" gives... Traceback (most recent call last): File "d:\Python23\Lib\idlelib\idle.pyw", line 4, in ? main() File "D:\Python23\lib\idlelib\PyShell.py", line 1269, in main root = Tk(className="Idle") File "D:\Python23\lib\lib-tk\Tkinter.py", line 1564, in __init__ self.tk = _tkinter.create(screenName, baseName, className) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {d:\ruby\tcl\lib\tcl8.3} {d:\ruby\tcl\lib\tcl8.3} d:/ruby/tcl/lib/tcl8.4 D:/Python23/lib/tcl8.4 D:/lib/tcl8.4 D:/library d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 16:55 Message: Logged In: YES user_id=11105 Can you provide some more details, please? Did you install Python in a directory containing spaces or not? Do you get a traceback if you try to start IDLE from the command line with python.exe instead of python2.exe: open a DOS box aka command prompt, and enter something like C:\Python23\python.exe "C:\Python23\Lib\idlelib\idle.pyw" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 From noreply at sourceforge.net Fri Oct 17 06:31:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 06:31:34 2003 Subject: [Python-bugs-list] [ python-Bugs-822974 ] Telnet.read_until() timeout parameter misleading Message-ID: Bugs item #822974, was opened at 2003-10-13 21:21 Message generated for change (Comment added) made by johahn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=822974&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Mitchel Quinn (mnquinn) Assigned to: Nobody/Anonymous (nobody) Summary: Telnet.read_until() timeout parameter misleading Initial Comment: Telnet.read_until(str,timeout) documentation reads as follows: Read until a given string, expected, is encountered or until timeout seconds have passed. When no match is found, return whatever is available instead, possibly the empty string. Raise EOFError if the connection is closed and no cooked data is available. However, the method does not behave in this manner. The method will only return if the call to select() on the socket is blocked for longer than the specified timeout. If there is a steady stream of data available, and it does not contain the specified string, this method will _NEVER_ return. A possible solution would be to subtract the elapsed time from the given timeout each time through the while loop. Here's a snippet of the code from telnetlib.py read_until(): if timeout is not None: s_args = s_args + (timeout,) while not self.eof and apply(select.select, s_args) == s_reply: i = max(0, len(self.cookedq)-n) self.fill_rawq() self.process_rawq() i = self.cookedq.find(match, i) if i >= 0: i = i+n buf = self.cookedq[:i] self.cookedq = self.cookedq[i:] return buf return self.read_very_lazy() ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-17 12:31 Message: Logged In: YES user_id=887415 I confirm everything Mitchel wrote + I have submitted a patch for this: http://sourceforge.net/tracker/index.php? func=detail&aid=825417&group_id=5470&atid=305470 ...johahn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=822974&group_id=5470 From noreply at sourceforge.net Fri Oct 17 07:46:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 07:47:03 2003 Subject: [Python-bugs-list] [ python-Bugs-824977 ] Memory error on AIX in email.Utils._qdecode Message-ID: Bugs item #824977, was opened at 2003-10-16 18:40 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart D. Gathman (customdesigned) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Memory error on AIX in email.Utils._qdecode Initial Comment: The following scriptlet works correctly on RedHat python2-2.2.3, but gets a MemoryError on AIX python-2.2.3. This is the only anomoly for AIX python I have seen. import email fp = open('analfail') msg = email.message_from_file(fp) for part in msg.walk(): if part.get_main_type() == 'text': txt = part.get_payload(decode=True) #del msg["content-transfer-encoding"] msg.set_payload(txt) fp.close() print msg.as_string() It doesn't matter whether the 'del' is there. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-17 12:46 Message: Logged In: YES user_id=6656 Why does binascii call calloc directly? Shouldn't it be calling PyMem_New? ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 21:14 Message: Logged In: YES user_id=142072 Might as well fix b2a_qp while we are at it: --- ./Modules/binascii.c.aix Mon Mar 17 06:34:43 2003 +++ ./Modules/binascii.c Thu Oct 16 16:08:25 2003 @@ -1036,7 +1036,7 @@ /* We allocate the output same size as input, this is overkill */ odata = (unsigned char *) calloc(1, datalen); - if (odata == NULL) { + if (odata == NULL && datalen > 0) { PyErr_NoMemory(); return NULL; } @@ -1206,7 +1206,7 @@ odata = (unsigned char *) calloc(1, odatalen); - if (odata == NULL) { + if (odata == NULL && odatalen > 0) { PyErr_NoMemory(); return NULL; } ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 21:00 Message: Logged In: YES user_id=142072 Fixed binascii as follows: --- ./Modules/binascii.c.bms Mon Mar 17 06:34:43 2003 +++ ./Modules/binascii.c Thu Oct 16 15:55:34 2003 @@ -1036,7 +1036,7 @@ /* We allocate the output same size as input, this is overkill */ odata = (unsigned char *) calloc(1, datalen); - if (odata == NULL) { + if (odata == NULL && datalen > 0) { PyErr_NoMemory(); return NULL; } This bug will manifest not just on AIX, but any system which returns NULL from malloc or calloc when allocated size is 0. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 18:47 Message: Logged In: YES user_id=142072 It looks like the problem is with a2b_qp in the binascii extension module. So I am changing the Category. ---------------------------------------------------------------------- Comment By: Stuart D. Gathman (customdesigned) Date: 2003-10-16 18:43 Message: Logged In: YES user_id=142072 I forgot to include the traceback. $ python t.py Traceback (most recent call last): File "t.py", line 8, in ? txt = part.get_payload(decode=True) File "/usr/local/lib/python2.2/email/Message.py", line 197, in get_payload return Utils._qdecode(payload) File "/usr/local/lib/python2.2/quopri.py", line 161, in decodestring return a2b_qp(s, header = header) MemoryError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824977&group_id=5470 From noreply at sourceforge.net Fri Oct 17 09:49:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 09:49:22 2003 Subject: [Python-bugs-list] [ python-Bugs-824947 ] strip on chr(0x1f) different with unicode Message-ID: Bugs item #824947, was opened at 2003-10-16 18:37 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824947&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Thomas B Hickey (thomasbhickey) Assigned to: M.-A. Lemburg (lemburg) Summary: strip on chr(0x1f) different with unicode Initial Comment: chr(0x1f) gets stripped from Unicode strings, but not from regular strings. I don't believe either should strip it. Python 2.3.1 (#47, Sep 23 2003, 23:47:32) [MSC v.1200 32 bit (Intel)] on win32 >>> sd = chr(0x1f) >>> sd.strip() '\x1f' >>> unicode(sd).strip() u'' ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-10-17 15:49 Message: Logged In: YES user_id=89016 The problem is that "\x1f" (UNIT SEPARATOR) is considered a space in str.isspace(), but not in unicode.isspace(): >>> u"\x1f".isspace() True >>> "\x1f".isspace() False For str, isspace() from the OS is used, but for unicode iswspace() or the unicode database is used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824947&group_id=5470 From noreply at sourceforge.net Fri Oct 17 10:43:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 10:43:54 2003 Subject: [Python-bugs-list] [ python-Bugs-824947 ] strip on chr(0x1f) different with unicode Message-ID: Bugs item #824947, was opened at 2003-10-16 18:37 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824947&group_id=5470 Category: Unicode Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Thomas B Hickey (thomasbhickey) Assigned to: M.-A. Lemburg (lemburg) Summary: strip on chr(0x1f) different with unicode Initial Comment: chr(0x1f) gets stripped from Unicode strings, but not from regular strings. I don't believe either should strip it. Python 2.3.1 (#47, Sep 23 2003, 23:47:32) [MSC v.1200 32 bit (Intel)] on win32 >>> sd = chr(0x1f) >>> sd.strip() '\x1f' >>> unicode(sd).strip() u'' ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-10-17 16:43 Message: Logged In: YES user_id=38388 Walter explained it all. ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-10-17 15:49 Message: Logged In: YES user_id=89016 The problem is that "\x1f" (UNIT SEPARATOR) is considered a space in str.isspace(), but not in unicode.isspace(): >>> u"\x1f".isspace() True >>> "\x1f".isspace() False For str, isspace() from the OS is used, but for unicode iswspace() or the unicode database is used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824947&group_id=5470 From noreply at sourceforge.net Fri Oct 17 11:16:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 11:17:04 2003 Subject: [Python-bugs-list] [ python-Bugs-824756 ] IDLE fails to start on Win2000 Message-ID: Bugs item #824756, was opened at 2003-10-16 13:51 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE fails to start on Win2000 Initial Comment: The new python-2.3.2-1.exe has not fixed the IDLE problem. I have two Windows 2000 machines (not running firewalls) on which IDLE does not start. Python itself works perfectly. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-10-17 17:16 Message: Logged In: YES user_id=11105 Ok, I'll close this with 'works for me'. > (But does this mean python and ruby cannot coexist on a Windows machine?) Maybe you should bug the ruby developers? ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2003-10-17 11:21 Message: Logged In: YES user_id=888261 Yes, removing TCL_LIBRARY set by ruby fixes the problem. Thanks for everybody's help. I am not a Windows person, otherwise I could have fixed this myself. We are told to trust auto-installers. Now I know not to. Back to linux for real work now... (But does this mean python and ruby cannot coexist on a Windows machine?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 22:42 Message: Logged In: YES user_id=31435 I prefer to keep the report open until the OP reports success or failure (or a week has gone by without hearing more). pythonw's woes wrt not reporting errors has been discussed several times before, but nobody has volunteered the work to "do something" about it. Good topic for python-dev -- it gets too much Linux-specific crud anyway . ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 21:32 Message: Logged In: YES user_id=11105 I didn't mean that the Python installer sets these envvars systemwide, I meant that Python should know where a usable Tcl/Tk is installed. How this is communicated to Tkinter I don't know. But, worse, I find it a shame that IDLE cannot start because of this (or another problem) without pythonw trying to give the poor user *any* hint about what's wrong. Why isn't it the default for pythonw to redirect stderr into a MessageBox? I suggest to close *this* bug with either "won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 21:17 Message: Logged In: YES user_id=31435 If Python set Tcl/Tk envars, it would be as anti-social as Ruby. If Ruby managed Tcl/Tk the way Python managed it, everyone would co-exist peacefully. pythonw has nowhere to display a traceback -- it doesn't have a console (and not having a console is the point of pythonw -- that one's not shallow ). "It would be nice" if it pythonw opened a message window to display tracebacks. As is, programs that try to write to stdout or stderr under pythonw can even crash (Windows doesn't complain if you try to write to stdout or stderr then, but they're hooked up to something that crashes on some systems if you write "too much"). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 20:50 Message: Logged In: YES user_id=11105 Hm, python.exe and pythonw.exe *could* set it's own envvars. Maybe. Or not. But anyway, shouldn't pythonw.exe be able to display tracebacks? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 19:46 Message: Logged In: YES user_id=31435 You installed Ruby. The Ruby installer is anti-social in the way it sets up Tcl/Tk. Look in your environment for envars starting with TCL and TK. The Ruby installer sets those, which forces every program trying to use Tcl or Tk to use Ruby's version of Tcl and Tk. There's nothing Python can do about that. Get rid of the envars and Python will run fine. ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2003-10-16 19:11 Message: Logged In: YES user_id=888261 There are no spaces in the path. d:\Python23\python.exe "d:\Python23\Lib\idlelib\idle.pyw" gives... Traceback (most recent call last): File "d:\Python23\Lib\idlelib\idle.pyw", line 4, in ? main() File "D:\Python23\lib\idlelib\PyShell.py", line 1269, in main root = Tk(className="Idle") File "D:\Python23\lib\lib-tk\Tkinter.py", line 1564, in __init__ self.tk = _tkinter.create(screenName, baseName, className) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {d:\ruby\tcl\lib\tcl8.3} {d:\ruby\tcl\lib\tcl8.3} d:/ruby/tcl/lib/tcl8.4 D:/Python23/lib/tcl8.4 D:/lib/tcl8.4 D:/library d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 18:55 Message: Logged In: YES user_id=11105 Can you provide some more details, please? Did you install Python in a directory containing spaces or not? Do you get a traceback if you try to start IDLE from the command line with python.exe instead of python2.exe: open a DOS box aka command prompt, and enter something like C:\Python23\python.exe "C:\Python23\Lib\idlelib\idle.pyw" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 From noreply at sourceforge.net Fri Oct 17 14:50:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 14:50:55 2003 Subject: [Python-bugs-list] [ python-Bugs-825676 ] code.InteractiveConsole interprets escape chars incorrectly Message-ID: Bugs item #825676, was opened at 2003-10-17 12: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=825676&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Richardson (markrichardson) Assigned to: Nobody/Anonymous (nobody) Summary: code.InteractiveConsole interprets escape chars incorrectly Initial Comment: code.InteractiveConsole interprets escape characters incorrectly. For example, it interprets "\t" the same as "\t", so it prints a tab instead of a backslash t. to reproduce: import sys import code class MyConsole(code.InteractiveConsole): def __init__(self): code.InteractiveConsole.__init__(self) # I tried it with runsource too. Same result. def run_code(self, cmdString): self.runcode(cmdString) def write(self, data): sys.__stdout__.write(data) instance = MyConsole() instance.run_code('print "\thello\tworld"') print "\thello\tworld" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825676&group_id=5470 From noreply at sourceforge.net Fri Oct 17 19:33:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 19:33:44 2003 Subject: [Python-bugs-list] [ python-Bugs-790162 ] a bug in IDLE on Python 2.3 i think Message-ID: Bugs item #790162, was opened at 2003-08-17 13:18 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790162&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed Resolution: Works For Me Priority: 3 Submitted By: Ricardo Nunes Cerqueira (caifas1800) Assigned to: Kurt B. Kaiser (kbk) Summary: a bug in IDLE on Python 2.3 i think Initial Comment: Hi, my name is Ricardo and i think there is a bug in the new release of Python 2.3. When i open a .py file with IDLE(after opening IDLE i open another .py file with it) the second window does not close after clicking the respective button, only the first(when i click the first window of IDLE) that has no code inserted, after trying to close the group(2 windows) only the first (the first IDLE window with no code inserted) closes leaving the other with code inserted open. i'm using Python 2.3 on Windows XP under an Intel PIII 1000EB FC-PGA. What i described happens after i open Python win then i open IDLE and then i open a .py file with IDLE, and when i try to close the .py and i can't. thanks ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-09-05 18:51 Message: Logged In: YES user_id=149084 Assuming that IDLE is configured to open a shell (the default action), then opening a .py file and closing that .py window works for me. Assuming that IDLE is configured to open an edit window, it comes up empty. If you then open a .py, the empty window is replaced with the whatever.py file and can be closed. Works for me. Assuming you start python, and then in the interactive window "import idle", the windows open and close correctly, as far as I can tell. I'm using XP / SP 1 / P4 2.4 Please provide (in short sentences) a precise recipe to reproduce your problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=790162&group_id=5470 From noreply at sourceforge.net Fri Oct 17 20:22:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 20:22:30 2003 Subject: [Python-bugs-list] [ python-Bugs-825810 ] reference to Built-In Types section in file() documentation Message-ID: Bugs item #825810, was opened at 2003-10-17 20: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=825810&group_id=5470 Category: Documentation Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: ewan (gorku) Assigned to: Nobody/Anonymous (nobody) Summary: reference to Built-In Types section in file() documentation Initial Comment: The file() documentation in section 2.1 says: Return a new file object (described earlier under Built-in Types) but Built-in Types is the _next_ section; this should probably also be a link ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825810&group_id=5470 From noreply at sourceforge.net Fri Oct 17 23:36:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 17 23:36:54 2003 Subject: [Python-bugs-list] [ python-Bugs-824756 ] IDLE fails to start on Win2000 Message-ID: Bugs item #824756, was opened at 2003-10-16 07:51 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 Category: IDLE >Group: 3rd Party Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE fails to start on Win2000 Initial Comment: The new python-2.3.2-1.exe has not fixed the IDLE problem. I have two Windows 2000 machines (not running firewalls) on which IDLE does not start. Python itself works perfectly. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-17 23:36 Message: Logged In: YES user_id=31435 Ruby works fine on a box with Python installed, because Python doesn't interfere with Ruby. It's Python that suffers, because Ruby interferes with Python -- but it only interferes to the extent that a Python program wants to use Tcl/Tk. You'll get the same kinds of problems on Linux (or any other OS) if some package installs an incompatible version of an external package to a shared area -- or, analogous to what Ruby does here, forces an envar setting that screws some other program you're running. Note that the Python installer leaves your Windows envars entirely alone. That's simply sane practice. I don't know why Ruby's installer messes with them. Changed Group to 3rdParty, and leaving Closed. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-17 11:16 Message: Logged In: YES user_id=11105 Ok, I'll close this with 'works for me'. > (But does this mean python and ruby cannot coexist on a Windows machine?) Maybe you should bug the ruby developers? ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2003-10-17 05:21 Message: Logged In: YES user_id=888261 Yes, removing TCL_LIBRARY set by ruby fixes the problem. Thanks for everybody's help. I am not a Windows person, otherwise I could have fixed this myself. We are told to trust auto-installers. Now I know not to. Back to linux for real work now... (But does this mean python and ruby cannot coexist on a Windows machine?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 16:42 Message: Logged In: YES user_id=31435 I prefer to keep the report open until the OP reports success or failure (or a week has gone by without hearing more). pythonw's woes wrt not reporting errors has been discussed several times before, but nobody has volunteered the work to "do something" about it. Good topic for python-dev -- it gets too much Linux-specific crud anyway . ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 15:32 Message: Logged In: YES user_id=11105 I didn't mean that the Python installer sets these envvars systemwide, I meant that Python should know where a usable Tcl/Tk is installed. How this is communicated to Tkinter I don't know. But, worse, I find it a shame that IDLE cannot start because of this (or another problem) without pythonw trying to give the poor user *any* hint about what's wrong. Why isn't it the default for pythonw to redirect stderr into a MessageBox? I suggest to close *this* bug with either "won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 15:17 Message: Logged In: YES user_id=31435 If Python set Tcl/Tk envars, it would be as anti-social as Ruby. If Ruby managed Tcl/Tk the way Python managed it, everyone would co-exist peacefully. pythonw has nowhere to display a traceback -- it doesn't have a console (and not having a console is the point of pythonw -- that one's not shallow ). "It would be nice" if it pythonw opened a message window to display tracebacks. As is, programs that try to write to stdout or stderr under pythonw can even crash (Windows doesn't complain if you try to write to stdout or stderr then, but they're hooked up to something that crashes on some systems if you write "too much"). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 14:50 Message: Logged In: YES user_id=11105 Hm, python.exe and pythonw.exe *could* set it's own envvars. Maybe. Or not. But anyway, shouldn't pythonw.exe be able to display tracebacks? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-16 13:46 Message: Logged In: YES user_id=31435 You installed Ruby. The Ruby installer is anti-social in the way it sets up Tcl/Tk. Look in your environment for envars starting with TCL and TK. The Ruby installer sets those, which forces every program trying to use Tcl or Tk to use Ruby's version of Tcl and Tk. There's nothing Python can do about that. Get rid of the envars and Python will run fine. ---------------------------------------------------------------------- Comment By: Keith Briggs (kbriggs) Date: 2003-10-16 13:11 Message: Logged In: YES user_id=888261 There are no spaces in the path. d:\Python23\python.exe "d:\Python23\Lib\idlelib\idle.pyw" gives... Traceback (most recent call last): File "d:\Python23\Lib\idlelib\idle.pyw", line 4, in ? main() File "D:\Python23\lib\idlelib\PyShell.py", line 1269, in main root = Tk(className="Idle") File "D:\Python23\lib\lib-tk\Tkinter.py", line 1564, in __init__ self.tk = _tkinter.create(screenName, baseName, className) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {d:\ruby\tcl\lib\tcl8.3} {d:\ruby\tcl\lib\tcl8.3} d:/ruby/tcl/lib/tcl8.4 D:/Python23/lib/tcl8.4 D:/lib/tcl8.4 D:/library d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" d:/ruby/tcl/lib/tcl8.3/init.tcl: version conflict for package "Tcl": have 8.4, need 8.3 version conflict for package "Tcl": have 8.4, need 8.3 while executing "package require -exact Tcl 8.3" (file "d:/ruby/tcl/lib/tcl8.3/init.tcl" line 19) invoked from within "source d:/ruby/tcl/lib/tcl8.3/init.tcl" ("uplevel" body line 1) invoked from within "uplevel #0 [list source $tclfile]" This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-16 12:55 Message: Logged In: YES user_id=11105 Can you provide some more details, please? Did you install Python in a directory containing spaces or not? Do you get a traceback if you try to start IDLE from the command line with python.exe instead of python2.exe: open a DOS box aka command prompt, and enter something like C:\Python23\python.exe "C:\Python23\Lib\idlelib\idle.pyw" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824756&group_id=5470 From noreply at sourceforge.net Sat Oct 18 05:34:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 18 05:34:44 2003 Subject: [Python-bugs-list] [ python-Bugs-642391 ] tempfile.mktemp() for directories Message-ID: Bugs item #642391, was opened at 2002-11-22 17:54 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642391&group_id=5470 Category: Documentation Group: Not a Bug >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: tempfile.mktemp() for directories Initial Comment: Hi! It would help newbies if you write in the documentation of tempfile.mktemp() That this function can be used to create unique filenames *or directories*. Something like this: mktemp() can be used to create filenames which can me used to create temporary files or directories. I know this, you know it, but newbies don't. Thank you for python and it's documentation! thomas ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-18 11:34 Message: Logged In: YES user_id=21627 This problem should not be fixed: mktemp is documented as unsafe and should not be used. Use mkdtemp instead to create directories. ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-01-05 05:45 Message: Logged In: YES user_id=531881 see patch 662475 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=642391&group_id=5470 From noreply at sourceforge.net Sat Oct 18 05:51:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 18 05:55:12 2003 Subject: [Python-bugs-list] [ python-Bugs-764839 ] Old bsddb version picked by setup.py Message-ID: Bugs item #764839, was opened at 2003-07-02 21:39 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764839&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Josh Hoyt (joshhoyt) Assigned to: Martin v. L?wis (loewis) Summary: Old bsddb version picked by setup.py Initial Comment: I have two versions of Berkeley DB in the standard include path. The code in setup.py finds the newer version first (db4) and then finds the older version (db3) later in scanning standard includes. This means that the bsddb module is built against the older rather than the newer version. The attached patch to setup.py records all standard headers that are found and lets the db_search_order list choose which version of the library to link against. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-18 11:51 Message: Logged In: YES user_id=21627 I see. Please notice that setting CFLAGS prior to compilation is not really supported, so I recommend that you don't set CFLAGS - BerkeleyDB 4.1 should still be found in /usr/local, or (preferred) /usr/local/BerkeleyDB.4.1 ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2003-07-07 18:29 Message: Logged In: YES user_id=693077 I am running Debian GNU/Linux, unstable, with GCC 3.3.1. I added the following to my environment prior to building Python: LDFLAGS=-L${HOME}/local/lib CFLAGS-I${HOME}/local/include My local build of Berkeley DB is version 4.1.25, and the system version is 3.2.9. I hope that makes the situation clear. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-07 07:00 Message: Logged In: YES user_id=21627 Can you please be more explicit? What operating system are you using, what compiler, how did you add something to the include path, what was the version of BerkeleyDB that was installed, what was the version that you installed yourself, and where did you install it? In short, you shouldn't add something to the include path. For gcc, I don't even see how you *could* add something to the include path. ---------------------------------------------------------------------- Comment By: Josh Hoyt (joshhoyt) Date: 2003-07-07 04:29 Message: Logged In: YES user_id=693077 There is a system Berkeley DB library and I have a locally built newer Berkeley DB library. When building Python, I added my local build to the include path and to the library path. Am I missing a more explicit way of selecting the library short of editing Setup in the Modules directory? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-06 11:46 Message: Logged In: YES user_id=21627 I'm not quite sure how this could ever happen. Are you saying that you have two different versions of db.h, both on your standard search path? In what specific locations? This is asking for trouble, and it might be better if setup.py would actively reject that scenario, refusing to build _bsddb. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764839&group_id=5470 From noreply at sourceforge.net Sat Oct 18 05:59:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 18 05:59:48 2003 Subject: [Python-bugs-list] [ python-Bugs-825676 ] code.InteractiveConsole interprets escape chars incorrectly Message-ID: Bugs item #825676, was opened at 2003-10-17 20:50 Message generated for change (Comment added) made by johahn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825676&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Richardson (markrichardson) Assigned to: Nobody/Anonymous (nobody) Summary: code.InteractiveConsole interprets escape chars incorrectly Initial Comment: code.InteractiveConsole interprets escape characters incorrectly. For example, it interprets "\t" the same as "\t", so it prints a tab instead of a backslash t. to reproduce: import sys import code class MyConsole(code.InteractiveConsole): def __init__(self): code.InteractiveConsole.__init__(self) # I tried it with runsource too. Same result. def run_code(self, cmdString): self.runcode(cmdString) def write(self, data): sys.__stdout__.write(data) instance = MyConsole() instance.run_code('print "\thello\tworld"') print "\thello\tworld" ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-18 11:59 Message: Logged In: YES user_id=887415 You should use the r prefix when passing strings to InteractiveConsole to prevent the string from beeing parsed twice. This works fine: >>> instance.run_code(r'print "\thello\tworld"') The strange behaviour you are experiencing lies with the exec statement... it boiles down to: >>> exec 'print"\thello\tworld"' hello world >>> print "\thello\tworld" \thello\tworld The cause is that the inner string in the first call is parsed twice... first double backslash '\' is reduced to '\' prior to the exec statement is executed... then before print is called the string is parsed again and '\t' becomes a tab. I wouldn't classify this as a bug, rather a gotcha. Think of what this line means: >>> exec 'print "hello\nworld"' ...johahn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825676&group_id=5470 From noreply at sourceforge.net Sat Oct 18 11:36:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 18 11:36:33 2003 Subject: [Python-bugs-list] [ python-Bugs-826013 ] Class Problem with repr and getattr on PY2.3.2 Message-ID: Bugs item #826013, was opened at 2003-10-18 15: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=826013&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Frank Timmermann (regenkind) Assigned to: Nobody/Anonymous (nobody) Summary: Class Problem with repr and getattr on PY2.3.2 Initial Comment: Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 IDLE 1.0 >>> class A: def __init__(self): self.x=1 def __repr__(self): return "REPR" def __getattr__(self,name): return "GETATTR" >>> a=A() >>> a REPR >>> print a Traceback (most recent call last): File "", line 1, in -toplevel- print a TypeError: 'str' object is not callable >>> if a: print 1 Traceback (most recent call last): File "", line 1, in -toplevel- if a: print 1 TypeError: 'str' object is not callable >>> Everything works fine without the __getattr__ code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826013&group_id=5470 From noreply at sourceforge.net Sat Oct 18 11:49:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 18 11:49:29 2003 Subject: [Python-bugs-list] [ python-Bugs-807871 ] tkMessageBox.askyesno wrong result Message-ID: Bugs item #807871, was opened at 2003-09-17 15:18 Message generated for change (Comment added) made by regenkind You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Paul Perkins (ranger1) Assigned to: Nobody/Anonymous (nobody) Summary: tkMessageBox.askyesno wrong result Initial Comment: Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. ---------------------------------------------------------------------- Comment By: Frank Timmermann (regenkind) Date: 2003-10-18 15:49 Message: Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 From noreply at sourceforge.net Sat Oct 18 13:43:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 18 13:43:38 2003 Subject: [Python-bugs-list] [ python-Bugs-789995 ] access fails on Windows with Unicode file name Message-ID: Bugs item #789995, was opened at 2003-08-17 09:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789995&group_id=5470 Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: Martin v. L?wis (loewis) Summary: access fails on Windows with Unicode file name Initial Comment: Using current CVS version of Python 2.4 on Windows 2000. The os.access function fails when the filename argument is a Unicode string: File "test_pep277.py", line 103, in test_directory os.access(filename,os.R_OK) UnicodeEncodeError: 'ascii' codec can't encode character '\udf' in position 0: ordinal not in range(128) I will upload a patch to fix this in the patch manager. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-18 19:43 Message: Logged In: YES user_id=21627 I cannot reproduce this. Are you sure you are using the latest posixmodule.c? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789995&group_id=5470 From noreply at sourceforge.net Sat Oct 18 14:42:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 18 14:43:13 2003 Subject: [Python-bugs-list] [ python-Bugs-823209 ] cmath.log doesn't have the same interface as math.log. Message-ID: Bugs item #823209, was opened at 2003-10-13 23:23 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823209&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: cmath.log doesn't have the same interface as math.log. Initial Comment: Somewhere along the way, math.log gained an optional "base" argument. cmath.log is still missing it. >>> print math.log.__doc__ log(x[, base]) -> the logarithm of x to the given base. If the base not specified, returns the natural logarithm (base e) of x. >>> print cmath.log.__doc__ log(x) Return the natural logarithm of x. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-18 13:42 Message: Logged In: YES user_id=139865 See patch #826074 for a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823209&group_id=5470 From noreply at sourceforge.net Sat Oct 18 18:14:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 18 18:14:32 2003 Subject: [Python-bugs-list] [ python-Bugs-789995 ] access fails on Windows with Unicode file name Message-ID: Bugs item #789995, was opened at 2003-08-17 17:10 Message generated for change (Comment added) made by nyamatongwe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789995&group_id=5470 Category: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: Martin v. L?wis (loewis) Summary: access fails on Windows with Unicode file name Initial Comment: Using current CVS version of Python 2.4 on Windows 2000. The os.access function fails when the filename argument is a Unicode string: File "test_pep277.py", line 103, in test_directory os.access(filename,os.R_OK) UnicodeEncodeError: 'ascii' codec can't encode character '\udf' in position 0: ordinal not in range(128) I will upload a patch to fix this in the patch manager. ---------------------------------------------------------------------- >Comment By: Neil Hodgson (nyamatongwe) Date: 2003-10-19 08:14 Message: Logged In: YES user_id=12579 This bug was submitted in August at the same time as the patch, so was before revision 2.303. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-19 03:43 Message: Logged In: YES user_id=21627 I cannot reproduce this. Are you sure you are using the latest posixmodule.c? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789995&group_id=5470 From noreply at sourceforge.net Sat Oct 18 18:24:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 18 18:24:52 2003 Subject: [Python-bugs-list] [ python-Bugs-789995 ] access fails on Windows with Unicode file name Message-ID: Bugs item #789995, was opened at 2003-08-17 09:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789995&group_id=5470 Category: Unicode Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neil Hodgson (nyamatongwe) Assigned to: Martin v. L?wis (loewis) Summary: access fails on Windows with Unicode file name Initial Comment: Using current CVS version of Python 2.4 on Windows 2000. The os.access function fails when the filename argument is a Unicode string: File "test_pep277.py", line 103, in test_directory os.access(filename,os.R_OK) UnicodeEncodeError: 'ascii' codec can't encode character '\udf' in position 0: ordinal not in range(128) I will upload a patch to fix this in the patch manager. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-19 00:24 Message: Logged In: YES user_id=21627 Ok, closing it as fixed. ---------------------------------------------------------------------- Comment By: Neil Hodgson (nyamatongwe) Date: 2003-10-19 00:14 Message: Logged In: YES user_id=12579 This bug was submitted in August at the same time as the patch, so was before revision 2.303. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-18 19:43 Message: Logged In: YES user_id=21627 I cannot reproduce this. Are you sure you are using the latest posixmodule.c? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789995&group_id=5470 From noreply at sourceforge.net Sun Oct 19 10:21:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 19 10:21:48 2003 Subject: [Python-bugs-list] [ python-Bugs-695688 ] Problems with non-greedy match groups Message-ID: Bugs item #695688, was opened at 2003-03-01 18:52 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695688&group_id=5470 Category: Regular Expressions Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Daniel (kamek) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Problems with non-greedy match groups Initial Comment: The problem is better explained with this code: import re regexp = re.compile(r'^begin ((.*?)X)?(.+) end$') print regexp.search('begin oneXtwo end').groups() # The above one will correctly print: # ('oneX', 'one', 'two') print regexp.search('begin two end').groups() # ...but the above one will print: # (None, 'two end', 'two') # If we change regexp's non-greedy # .*? into .*, it works as it should: # (None, None, 'two') The problem lies in sre; pre correctly matches the non- greedy version. ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2003-10-19 14:21 Message: Logged In: YES user_id=7887 Fixed in Python 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=695688&group_id=5470 From noreply at sourceforge.net Sun Oct 19 18:13:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 19 18:13:20 2003 Subject: [Python-bugs-list] [ python-Bugs-807871 ] tkMessageBox.askyesno wrong result Message-ID: Bugs item #807871, was opened at 2003-09-17 17:18 Message generated for change (Comment added) made by midramas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Paul Perkins (ranger1) Assigned to: Nobody/Anonymous (nobody) Summary: tkMessageBox.askyesno wrong result Initial Comment: Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-10-20 00:13 Message: Logged In: YES user_id=31511 Tested on Linux with python HEAD from cvs. Bug could be reproduced and is still present. ---------------------------------------------------------------------- Comment By: Frank Timmermann (regenkind) Date: 2003-10-18 17:49 Message: Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=807871&group_id=5470 From noreply at sourceforge.net Mon Oct 20 06:23:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 06:23:48 2003 Subject: [Python-bugs-list] [ python-Bugs-826756 ] email/Generator.py: Incorrect header output Message-ID: Bugs item #826756, was opened at 2003-10-20 12: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=826756&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Pronk (mjepronk) Assigned to: Nobody/Anonymous (nobody) Summary: email/Generator.py: Incorrect header output Initial Comment: I've found a small bug when using the email/Parser.py classes. When there is a long "Subject" header, it will be wrapped to multiple lines, which are preceded by a tab. This is undesired behaviour, because e-mail clients show this tab in the subject. Especially, Mozilla for Windows shows a strange square symbol. The following code in email/Generator.py (line 180) resolves the problem: else: # Header's got lots of smarts, so use it. if h.lower() == 'subject': cont_ws = ' ' else: cont_ws = '\t' print >> self._fp, Header( v, maxlinelen=self.__maxheaderlen, header_name=h, continuation_ws=cont_ws).encode() For more information you can e-mail me: matthias -at- rubberbiscuit.nl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826756&group_id=5470 From noreply at sourceforge.net Mon Oct 20 07:31:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 07:31:31 2003 Subject: [Python-bugs-list] [ python-Bugs-825676 ] code.InteractiveConsole interprets escape chars incorrectly Message-ID: Bugs item #825676, was opened at 2003-10-17 19:50 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825676&group_id=5470 Category: Python Library Group: Python 2.2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mark Richardson (markrichardson) >Assigned to: Michael Hudson (mwh) Summary: code.InteractiveConsole interprets escape chars incorrectly Initial Comment: code.InteractiveConsole interprets escape characters incorrectly. For example, it interprets "\t" the same as "\t", so it prints a tab instead of a backslash t. to reproduce: import sys import code class MyConsole(code.InteractiveConsole): def __init__(self): code.InteractiveConsole.__init__(self) # I tried it with runsource too. Same result. def run_code(self, cmdString): self.runcode(cmdString) def write(self, data): sys.__stdout__.write(data) instance = MyConsole() instance.run_code('print "\thello\tworld"') print "\thello\tworld" ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-20 12:31 Message: Logged In: YES user_id=6656 as johahn explains, you've been confused by multiple levels of escaping. closing. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-18 10:59 Message: Logged In: YES user_id=887415 You should use the r prefix when passing strings to InteractiveConsole to prevent the string from beeing parsed twice. This works fine: >>> instance.run_code(r'print "\thello\tworld"') The strange behaviour you are experiencing lies with the exec statement... it boiles down to: >>> exec 'print"\thello\tworld"' hello world >>> print "\thello\tworld" \thello\tworld The cause is that the inner string in the first call is parsed twice... first double backslash '\' is reduced to '\' prior to the exec statement is executed... then before print is called the string is parsed again and '\t' becomes a tab. I wouldn't classify this as a bug, rather a gotcha. Think of what this line means: >>> exec 'print "hello\nworld"' ...johahn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825676&group_id=5470 From noreply at sourceforge.net Mon Oct 20 07:33:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 07:34:00 2003 Subject: [Python-bugs-list] [ python-Bugs-826013 ] Class Problem with repr and getattr on PY2.3.2 Message-ID: Bugs item #826013, was opened at 2003-10-18 16:36 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826013&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Frank Timmermann (regenkind) >Assigned to: Michael Hudson (mwh) Summary: Class Problem with repr and getattr on PY2.3.2 Initial Comment: Python 2.3.2 (#49, Oct 2 2003, 20:02:00) [MSC v.1200 32 bit (Intel)] on win32 IDLE 1.0 >>> class A: def __init__(self): self.x=1 def __repr__(self): return "REPR" def __getattr__(self,name): return "GETATTR" >>> a=A() >>> a REPR >>> print a Traceback (most recent call last): File "", line 1, in -toplevel- print a TypeError: 'str' object is not callable >>> if a: print 1 Traceback (most recent call last): File "", line 1, in -toplevel- if a: print 1 TypeError: 'str' object is not callable >>> Everything works fine without the __getattr__ code. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-20 12:33 Message: Logged In: YES user_id=6656 you're returning a string in response to a request for __str__ and (I'd guess) __nonzero__. Don't do that, raise AttributeError instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826013&group_id=5470 From noreply at sourceforge.net Mon Oct 20 09:42:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 09:42:17 2003 Subject: [Python-bugs-list] [ python-Bugs-826756 ] email/Generator.py: Incorrect header output Message-ID: Bugs item #826756, was opened at 2003-10-20 06:23 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826756&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Pronk (mjepronk) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email/Generator.py: Incorrect header output Initial Comment: I've found a small bug when using the email/Parser.py classes. When there is a long "Subject" header, it will be wrapped to multiple lines, which are preceded by a tab. This is undesired behaviour, because e-mail clients show this tab in the subject. Especially, Mozilla for Windows shows a strange square symbol. The following code in email/Generator.py (line 180) resolves the problem: else: # Header's got lots of smarts, so use it. if h.lower() == 'subject': cont_ws = ' ' else: cont_ws = '\t' print >> self._fp, Header( v, maxlinelen=self.__maxheaderlen, header_name=h, continuation_ws=cont_ws).encode() For more information you can e-mail me: matthias -at- rubberbiscuit.nl ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826756&group_id=5470 From noreply at sourceforge.net Mon Oct 20 10:28:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 10:28:18 2003 Subject: [Python-bugs-list] [ python-Bugs-826897 ] Proto 2 pickle vs dict subclass Message-ID: Bugs item #826897, was opened at 2003-10-20 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=826897&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Peters (tim_one) Assigned to: Nobody/Anonymous (nobody) Summary: Proto 2 pickle vs dict subclass Initial Comment: >From c.l.py: """ From: Jimmy Retzlaff Sent: Thursday, October 16, 2003 1:56 AM To: python-list@python.org Subject: Pickle dict subclass instances using new protocol in PEP 307 I have a subclass of dict that acts kind of like Windows' file systems - keys are case insensitive but case preserving (keys are assumed to be strings, or at least they have to support .lower()). It's worked well for quite a while - it used to inherit from UserDict and it has inherited from dict since that became possible. I just tried to pickle an instance of this class for the first time using Python 2.3.2 on Windows. If I use protocols 0 (text) or 1 (binary) everything works great. If I use protocol 2 (PEP 307) then I have a problem when loading my pickle. Here is a small sample to illustrate: ###### import pickle class myDict(dict): def __init__(self, *args, **kwargs): self.x = 1 dict.__init__(self, *args, **kwargs) def __getstate__(self): print '__getstate__ returning', (self.copy(), self.x) return (self.copy(), self.x) def __setstate__(self, (d, x)): print '__setstate__' print ' object already in state:', self print ' x already in self:', 'x' in dir(self) self.x = x self.update(d) def __setitem__(self, key, value): print '__setitem__', (key, value) dict.__setitem__(self, key, value) d = myDict() d['key'] = 'value' protocols = [(0, 'Text'), (1, 'Binary'), (2, 'PEP 307')] for protocol, description in protocols: print '--------------------------------------' print 'Pickling with Protocol %s (%s)' % (protocol, description) pickle.dump(d, file('test.pickle', 'wb'), protocol) del d print 'Unpickling' d = pickle.load(file('test.pickle', 'rb')) ###### When run it prints: __setitem__ ('key', 'value') - self.x exists: True -------------------------------------- Pickling with Protocol 0 (Text) __getstate__ returning ({'key': 'value'}, 1) Unpickling __setstate__ object already in state: {'key': 'value'} x already in self: False -------------------------------------- Pickling with Protocol 1 (Binary) __getstate__ returning ({'key': 'value'}, 1) Unpickling __setstate__ object already in state: {'key': 'value'} x already in self: False -------------------------------------- Pickling with Protocol 2 (PEP 307) __getstate__ returning ({'key': 'value'}, 1) Unpickling __setitem__ ('key', 'value') - self.x exists: False __setstate__ object already in state: {'key': 'value'} x already in self: False The problem I'm having stems from the fact that the subclass' __setitem__ is called before __setstate__ when loading a protocol 2 pickle (the subclass' __setitem__ is not called at all with protocols 0 or 1). If I don't define __get/setstate__ then I have the same problem in that the subclass' __setitem__ is called before the subclass' instance variables are created by the pickle mechanism. I need to access one of those instance variables in my __setitem__. I suppose my question is one of practicality. I'd like my class instances to work with all pickle protocols. Am I getting too fancy trying to inherit from dict? Should I go back to UserDict or maybe to DictMixin? Should I submit a bug report on this, or am I getting too close to internals to expect a certain behavior across pickle protocols? """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=826897&group_id=5470 From noreply at sourceforge.net Mon Oct 20 11:31:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 11:31:43 2003 Subject: [Python-bugs-list] [ python-Bugs-825676 ] code.InteractiveConsole interprets escape chars incorrectly Message-ID: Bugs item #825676, was opened at 2003-10-17 12:50 Message generated for change (Comment added) made by markrichardson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825676&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Mark Richardson (markrichardson) Assigned to: Michael Hudson (mwh) Summary: code.InteractiveConsole interprets escape chars incorrectly Initial Comment: code.InteractiveConsole interprets escape characters incorrectly. For example, it interprets "\t" the same as "\t", so it prints a tab instead of a backslash t. to reproduce: import sys import code class MyConsole(code.InteractiveConsole): def __init__(self): code.InteractiveConsole.__init__(self) # I tried it with runsource too. Same result. def run_code(self, cmdString): self.runcode(cmdString) def write(self, data): sys.__stdout__.write(data) instance = MyConsole() instance.run_code('print "\thello\tworld"') print "\thello\tworld" ---------------------------------------------------------------------- >Comment By: Mark Richardson (markrichardson) Date: 2003-10-20 09:31 Message: Logged In: YES user_id=889309 Thanks for the clarification on this one. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-20 05:31 Message: Logged In: YES user_id=6656 as johahn explains, you've been confused by multiple levels of escaping. closing. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-18 03:59 Message: Logged In: YES user_id=887415 You should use the r prefix when passing strings to InteractiveConsole to prevent the string from beeing parsed twice. This works fine: >>> instance.run_code(r'print "\thello\tworld"') The strange behaviour you are experiencing lies with the exec statement... it boiles down to: >>> exec 'print"\thello\tworld"' hello world >>> print "\thello\tworld" \thello\tworld The cause is that the inner string in the first call is parsed twice... first double backslash '\' is reduced to '\' prior to the exec statement is executed... then before print is called the string is parsed again and '\t' becomes a tab. I wouldn't classify this as a bug, rather a gotcha. Think of what this line means: >>> exec 'print "hello\nworld"' ...johahn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825676&group_id=5470 From noreply at sourceforge.net Mon Oct 20 14:26:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 14:26:22 2003 Subject: [Python-bugs-list] [ python-Bugs-824371 ] ntpath.expandvars doesn't expand Windows-style variables. Message-ID: Bugs item #824371, was opened at 2003-10-15 22:32 Message generated for change (Comment added) made by johahn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824371&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: ntpath.expandvars doesn't expand Windows-style variables. Initial Comment: ntpath.expandvars is exactly the same as posixpath.expandvars -- it only expands $vars. But in windows, environment variables are represented by %vars%, not $vars. I can write a patch if necessary. Having read the code, I noticed that it went to great lengths to do what could quite easily be done with a regular expression, so I assume using regular expressions isn't kosher in the *path modules? ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-20 20:26 Message: Logged In: YES user_id=887415 Hi Jeremy The purpose of path.expandvars is to retrieve environment variables in a platform independant way into a user supplied string, as in path.expandvars('$PYTHON/Lib/site-packages'). Using %vars% on windows and $vars on unix would make the method pointless. So this is no bug, though it might be explained a little vague in the docstring (IMHO the overall purpose and the phrase "left unchanged" are both unclear): >>> help(path.expandvars) Help on function expandvars in module ntpath: expandvars(path) Expand shell variables of form $var and ${var}. Unknown variables are left unchanged. Though, the module docs offer a better explanation: "Return the argument with environment variables expanded. Substrings of the form "$name" or "${name}" are replaced by the value of environment variable name. Malformed variable names and references to non-existing variables are left unchanged. On the Macintosh, this always returns path unchanged." Still, what does "unchanged" mean? On my windows system non-existing variables are IGNORED, they are not left unchanged anywhere: >>> path.expandvars('$MADEUP/Lib/site-packages') '/Lib/site-packages' Is it me or is that a bug? :) ...johahn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824371&group_id=5470 From noreply at sourceforge.net Mon Oct 20 17:02:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 17:02:35 2003 Subject: [Python-bugs-list] [ python-Feature Requests-814689 ] sendmsg operation for unix sockets Message-ID: Feature Requests item #814689, was opened at 2003-09-29 21:58 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=814689&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: paul rubin (phr) Assigned to: Nobody/Anonymous (nobody) Summary: sendmsg operation for unix sockets Initial Comment: The socket module doesn't seem to support the sendmsg operation for AF_UNIX sockets, at least in Python 2.2.2 under Linux. This is needed to send ancillary messages to sockets. Those in turn allow a process to see the user id of its peer, allows sending file descriptors to other processes (needed for anything like User Mode Linux so that non-root processes can open privileged ports), and so forth. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-20 23:02 Message: Logged In: YES user_id=21627 Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=814689&group_id=5470 From noreply at sourceforge.net Mon Oct 20 17:07:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 17:07:18 2003 Subject: [Python-bugs-list] [ python-Feature Requests-793802 ] class for function calls that are not thread safe Message-ID: Feature Requests item #793802, was opened at 2003-08-23 18:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793802&group_id=5470 Category: Threads Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus Elfring (elfring) Assigned to: Nobody/Anonymous (nobody) Summary: class for function calls that are not thread safe Initial Comment: I would like that a class will be added to perform thread unsafe function or method calls in an easy way like I describe it in the request "https://sourceforge.net/mailarchive/forum.php?thread_id=1585197&forum_id=24972" for the TCL thread package. The description "http://zthread.sourceforge.net/html/classZThread_1_1SynchronousExecutor.html" seems to come near what I want. But I think that there is a little bit missing. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-20 23:07 Message: Logged In: YES user_id=21627 That feature is already available. You can easily provide a module-global mutex that is used to protect all entry points of some library. See _tkinter for one example, and socketmodule.c for another. ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2003-09-07 15:02 Message: Logged In: YES user_id=572001 I am looking for a monitor implementation that has got the scope of a library or package and not a single synchronized method or block like it is in Java. A function object will get this monitor as a parameter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793802&group_id=5470 From noreply at sourceforge.net Mon Oct 20 17:09:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 17:09:44 2003 Subject: [Python-bugs-list] [ python-Feature Requests-793798 ] Redirect file output into variables Message-ID: Feature Requests item #793798, was opened at 2003-08-23 17:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793798&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Markus Elfring (elfring) Assigned to: Nobody/Anonymous (nobody) Summary: Redirect file output into variables Initial Comment: The PHP programming language provides output control functions (http://de.php.net/manual/en/ref.outcontrol.php, e. g. "ob_get_contents"). I am looking for similar functionality to use with phyton. 1. I suggest to add a parameter that specifies a variable name. open(file, flags[, mode[, variable name]]) fdopen(fd[, mode[, bufsize[, variable name]]]) 2. Another technique is to implement a virtual file system that converts variables into special files. Has anybody tried to create a file system interface for variables before? A code example can be found with a similar feature request for TCL. https://sourceforge.net/tracker/?func=detail&aid=792990&group_id=10894&atid=360894 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-20 23:09 Message: Logged In: YES user_id=21627 This is already available. StringIO/cStringIO allow readily to output streams into memory. Use it like this variable = cStringIO.StringIO() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793798&group_id=5470 From noreply at sourceforge.net Mon Oct 20 18:46:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 18:46:38 2003 Subject: [Python-bugs-list] [ python-Bugs-827190 ] wrong error message of islice indexing Message-ID: Bugs item #827190, was opened at 2003-10-21 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=827190&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: wrong error message of islice indexing Initial Comment: If you pass negative values to itertools.islice, you get a wrong error message. Indices for itertools.islice() may be non-negative integers(zero is included), but the error message says that they must be positive. I think the message needs to be corrected. >>> from itertools import islice >>> l = range(5) >>> islice(l, 0, None) >>> islice(l, -1, None) Traceback (most recent call last): File "", line 1, in ? ValueError: Indices for islice() must be positive. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827190&group_id=5470 From noreply at sourceforge.net Mon Oct 20 19:41:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 19:41:32 2003 Subject: [Python-bugs-list] [ python-Bugs-827209 ] List comprehensions leaking control variable name deprecated Message-ID: Bugs item #827209, was opened at 2003-10-20 23: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=827209&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: List comprehensions leaking control variable name deprecated Initial Comment: According to the email thread starting: http://mail.python.org/pipermail/python-dev/2003- October/039081.html the control variable name in a list comprehension should not be leaked and any use of such a leaked name is deprecated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&group_id=5470 From noreply at sourceforge.net Mon Oct 20 20:04:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 20:04:34 2003 Subject: [Python-bugs-list] [ python-Bugs-827209 ] List comprehensions leaking control variable name deprecated Message-ID: Bugs item #827209, was opened at 2003-10-20 19:41 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: List comprehensions leaking control variable name deprecated Initial Comment: According to the email thread starting: http://mail.python.org/pipermail/python-dev/2003- October/039081.html the control variable name in a list comprehension should not be leaked and any use of such a leaked name is deprecated. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-20 20:04 Message: Logged In: YES user_id=593130 Ref Man 5.2.4 List displays: suggested addition at end. Using leaked 'for ' control variables outside the list display is deprecated and will not work when the bug is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&group_id=5470 From noreply at sourceforge.net Mon Oct 20 23:53:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 20 23:53:34 2003 Subject: [Python-bugs-list] [ python-Bugs-827260 ] Parameter is misnamed in str.replace documentation. Message-ID: Bugs item #827260, was opened at 2003-10-20 23: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=827260&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Parameter is misnamed in str.replace documentation. Initial Comment: >>> print str.replace.__doc__ S.replace (old, new[, maxsplit]) -> string Return a copy of string S with all occurrences of substring old replaced by new. If the optional argument maxsplit is given, only the first maxsplit occurrences are replaced. --- Honestly, that optional parameter really shouldn't be called "maxsplit" since there's no splitting going on. Just plain "max" would be better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827260&group_id=5470 From noreply at sourceforge.net Tue Oct 21 08:51:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 08:51:53 2003 Subject: [Python-bugs-list] [ python-Bugs-818201 ] distutils: clean -b ignored; set_undefined_options doesn't Message-ID: Bugs item #818201, was opened at 2003-10-05 13:37 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818201&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Nicholas Riley (nriley) >Assigned to: A.M. Kuchling (akuchling) Summary: distutils: clean -b ignored; set_undefined_options doesn't Initial Comment: I reported this on the distutils-sig list and didn't receive any response. I'd be happy to provide a patch, but I'm not sure which way to go. Here's something that I think should work: % python setup.py --help clean [...] Options for 'clean' command: --build-base (-b) base build directory (default: 'build.build-base') % python setup.py clean -b ../builds running clean Nothing happens. This works, however: % python setup.py build -b ../builds clean running build running build_py running build_ext running config gcc -E -I/Library/Frameworks/Python.framework/Versions/ 2.3/include/python2.3 -o_configtest.i _configtest.c removing: _configtest.c _configtest.i running clean removing '../builds/temp.darwin-6.8-Power_Macintosh-2.3' (and everything under it) The logic to set build_temp from build_base (-b) is only present in the build command, not in the clean command. The code to set this option runs from clean.set_undefined_options. But it's clean's build_base option which is set at the time, not build's, so it propagates an empty path. The test command class I found posted to the distutils-sig mailing list has a workaround for the above problem, which looks like this: def finalize_options(self): build = self.distribution.get_command_obj('build') build_options = ('build_base', 'build_purelib', 'build_platlib') for option in build_options: setattr(build, option, getattr(self, option)) build.ensure_finalized() for option in build_options: setattr(self, option, getattr(build, option)) and doesn't call self.set_undefined_options at all, though the last three lines could be replaced by it. There are several solutions I can think of: - set_undefined_options should be changed to propagate set options to the source command object before calling src_cmd_obj.ensure_finalized. - another method should be added to the cmd class, which does the above propagation then calls set_undefined_options. - a workaround such as the one above should be placed in the distutils.command.clean.clean class. Does this make sense? Unless there's a huge compatibility issue, I'd favor the first option, but my experience with distutils is limited. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818201&group_id=5470 From noreply at sourceforge.net Tue Oct 21 08:53:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 08:53:40 2003 Subject: [Python-bugs-list] [ python-Bugs-814606 ] 5454 - documentation wrong for ossaudiodev mixer device Message-ID: Bugs item #814606, was opened at 2003-09-29 14:16 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814606&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alfred Morgan (zectbumo) >Assigned to: Greg Ward (gward) Summary: 5454 - documentation wrong for ossaudiodev mixer device Initial Comment: http://www.python.org/doc/current/lib/mixer-device-objects.html methods controls() in the mixer device object have sample code that does not work. It seems that every reference in the document to the channels() method should be controls(). Also stereocontrols() references channels() and that should be controls() as well. -alfred python: 2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814606&group_id=5470 From noreply at sourceforge.net Tue Oct 21 09:04:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 09:04:08 2003 Subject: [Python-bugs-list] [ python-Bugs-528295 ] asyncore unhandled write event Message-ID: Bugs item #528295, was opened at 2002-03-10 19:34 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Carl J. Nobile (cnobile) Assigned to: A.M. Kuchling (akuchling) Summary: asyncore unhandled write event Initial Comment: I'm getting an unhandled write event on a handle_accept callback in asyncore.dispatch. This worked fine in python-2.1.1, but now seems to be broken in python-2.2. This happens when I send a SIGHUP to reread my config file. The signal lets me break out of the asyncore.loop() to reread the configuration and restart the server. The self.accept() method returns a TypeNone instead of the expected tuple when it is called in handle_accept. I've written a database key server which is a fairly large package and is dependent on a few other packages, so sending the code would not be too easy. If I can duplicate the problem in a few lines of code I will send it along at a later date. Thanks for your attention. Carl ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-10-21 09:04 Message: Logged In: YES user_id=11375 See the thread starting at http://mail.python. org/pipermail/python-dev/2002-March/021631.html . >From that thread, the consensus was that an exception should be raised. I'll close this bug. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 21:34 Message: Logged In: YES user_id=357491 Was this ever brought up or resolved on python-dev like Andrew planned? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-22 12:24 Message: Logged In: YES user_id=11375 Revision 1.25 of asyncore.py is responsible. It catches EINTR and silently swallows the error, so sending signals to the process now doesn't cause it to exit asyncore's loop() at all. I don't see any unhandled write event at all. I'm not sure what to do here, and will take it up on python-dev. ---------------------------------------------------------------------- Comment By: Carl J. Nobile (cnobile) Date: 2002-03-20 22:47 Message: Logged In: YES user_id=482117 Okay, The version of asyncore.py from 2.1.1 when put into the 2.2 release solves the problem, so the bug seems to be in asyncore.py. I have cobbled together a server that displays the same error and am including it here. When run in 2.1.1 it works fine, reloading the config (just a print) with a kill -1 pid and terminating with a kill pid. Carl ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-16 15:36 Message: Logged In: YES user_id=11375 The asyncore.py in 2.1.1 seems to be revision 1.10 of the file; it's rev. 1.28 in 2.2 and is now at 1.30, so there have been a number of changes to asyncore, though none seem relevant. Did you try your code on 2.2 with the 2.1.1 asyncore? That would let us figure out if it's due to a change in asyncore or the underlying socket or select module. (Actually, another thing to check is whether the select or the poll module is being used; maybe that changed for you between 2.1.1 and 2.2.) ---------------------------------------------------------------------- Comment By: Carl J. Nobile (cnobile) Date: 2002-03-14 21:52 Message: Logged In: YES user_id=482117 My question then is why didn't it do this when I ran my app with python 2.1.1. Something has changed in 2.2 and I don't think it was asyncore, I do know some work was done to the low level socket and select modules so they could handle IPV6. I understand why the None is being returned, but an accept shouldn't even be called on a write event coming from a select or poll. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-03-14 18:24 Message: Logged In: YES user_id=11375 Looking at the implementation of accept() in asyncore.py, it will return None when the socket is in non-blocking mode and the accept() would block. There's really nothing else accept() could return in this case, so you'll probably have to write your code to handle this case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470 From noreply at sourceforge.net Tue Oct 21 09:06:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 09:07:03 2003 Subject: [Python-bugs-list] [ python-Bugs-754455 ] sigwinch crashes python with curses Message-ID: Bugs item #754455, was opened at 2003-06-14 06:51 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754455&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: A.M. Kuchling (akuchling) Summary: sigwinch crashes python with curses Initial Comment: [forwarded from http://bugs.debian.org/178205] I'm not able to reproduce this bug in current 2.1/2.2. In 2.3 CVS 20030614, changing the window size of an xterm results in the crash The following code crashes. It does not occur when getkey () is not used. # Crash python import curses, signal, time, sys def sigwinch (signum, frame): return win = curses.initscr () signal.signal(signal.SIGWINCH, sigwinch) while 1: win.getkey () curses.endwin () Traceback (most recent call last): File "curs.py", line 9, in ? while 1: win.getkey () _curses.error: no input ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-10-21 09:06 Message: Logged In: YES user_id=11375 I agree with MvL; this is not a bug. An explanation of this point is worth including in the curses HOWTO at some point, though. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-14 09:43 Message: Logged In: YES user_id=21627 This is not a bug in Python. In _cursesmodule.c rev. 2.70, Patch #633635 from David M. Cooke was implemented, which makes the implementation match the documentation: getch([x, y]) Get a character. Note that the integer returned does not have to be in ASCII range: function keys, keypad keys and so on return numbers higher than 256. In no-delay mode, an exception is raised if there is no input. This exception is raised when the underlying wgetch returns ERR, so if there is a bug here, it might be in ncurses, for having wgetch return on window change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754455&group_id=5470 From noreply at sourceforge.net Tue Oct 21 09:52:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 09:52:41 2003 Subject: [Python-bugs-list] [ python-Bugs-827209 ] List comprehensions leaking control variable name deprecated Message-ID: Bugs item #827209, was opened at 2003-10-20 18:41 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: List comprehensions leaking control variable name deprecated Initial Comment: According to the email thread starting: http://mail.python.org/pipermail/python-dev/2003- October/039081.html the control variable name in a list comprehension should not be leaked and any use of such a leaked name is deprecated. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-10-21 08:52 Message: Logged In: YES user_id=44345 A good point raised by Michael Hudson is that foo = [x for x in R] print x will fail if R is empty (and x wasn't previously defined). All the more reason to deprecate its usage and suppress the leaking variable. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-20 19:04 Message: Logged In: YES user_id=593130 Ref Man 5.2.4 List displays: suggested addition at end. Using leaked 'for ' control variables outside the list display is deprecated and will not work when the bug is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&group_id=5470 From noreply at sourceforge.net Tue Oct 21 10:26:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 10:26:33 2003 Subject: [Python-bugs-list] [ python-Bugs-827209 ] List comprehensions leaking control variable name deprecated Message-ID: Bugs item #827209, was opened at 2003-10-21 01:41 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: List comprehensions leaking control variable name deprecated Initial Comment: According to the email thread starting: http://mail.python.org/pipermail/python-dev/2003- October/039081.html the control variable name in a list comprehension should not be leaked and any use of such a leaked name is deprecated. ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-21 16:26 Message: Logged In: YES user_id=43607 Actually, this is not different from $ python Python 2.4a0 (#2, Oct 14 2003, 11:28:48) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> for x in []: ... pass ... >>> print x Traceback (most recent call last): File "", line 1, in ? NameError: name 'x' is not defined >>> where x is also undefined after iteraring through an empty list. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-10-21 15:52 Message: Logged In: YES user_id=44345 A good point raised by Michael Hudson is that foo = [x for x in R] print x will fail if R is empty (and x wasn't previously defined). All the more reason to deprecate its usage and suppress the leaking variable. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-21 02:04 Message: Logged In: YES user_id=593130 Ref Man 5.2.4 List displays: suggested addition at end. Using leaked 'for ' control variables outside the list display is deprecated and will not work when the bug is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&group_id=5470 From noreply at sourceforge.net Tue Oct 21 11:48:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 11:48:55 2003 Subject: [Python-bugs-list] [ python-Bugs-816810 ] webbrowser.open hangs under certain conditions Message-ID: Bugs item #816810, was opened at 2003-10-02 17:00 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816810&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: webbrowser.open hangs under certain conditions Initial Comment: On Unix, if you have galeon installed and no BROWSER environment variable, webbrowser.open('http://...') will hang if there is no galeon running at the time of the call. The problem is, webbrowser.open calls "galeon ". If a galeon instance is running, the new invocation will signal the old about the URL and then exit. If there is no galeon instance running, the new instance will do the job itself and not exit, so the call to webbrowser.open() will hang until you exit galeon. Skip had this to say: In the meantime, it looks like if you modify the definition of cmd in Galeon._remote to cmd = "%s %s %s & >/dev/null 2>&1" % (self.name, raise_opt, action) that webbrowser.open() should return for you. I'm not sure the '&' is sufficient though. You may lose the Galeon instance if you then exit from the Python interpreter. In general, the code in webbrowser._remote() looks a bit hackish. I'm not sure I like this: rc = os.system(cmd) if rc: import time os.system("%s >/dev/null 2>&1 &" % self.name) time.sleep(PROCESS_CREATION_DELAY) rc = os.system(cmd) Oh well, it's what we're stuck with... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=816810&group_id=5470 From noreply at sourceforge.net Tue Oct 21 11:48:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 11:48:59 2003 Subject: [Python-bugs-list] [ python-Bugs-820344 ] Ref Man Index: Symbols -- Latex leak Message-ID: Bugs item #820344, was opened at 2003-10-08 19:39 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820344&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Terry J. Reedy (tjreedy) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Ref Man Index: Symbols -- Latex leak Initial Comment: Current online Ref Manual, Index, Symbols section has following text which looks like untranslated Latex: \textttNone object \textttNotImplemented object ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820344&group_id=5470 From noreply at sourceforge.net Tue Oct 21 11:48:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 11:49:13 2003 Subject: [Python-bugs-list] [ python-Bugs-817742 ] Need " new style note" Message-ID: Bugs item #817742, was opened at 2003-10-04 11:26 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817742&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Abrahams (david_abrahams) >Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: Need "new style note" Initial Comment: When you split my patch into http://www.python.org/doc/current/ref/new-style- attribute-access.html and http://www.python.org/doc/current/ref/descriptors.html, the descriptors info doesn't say "new style classes only anymore" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817742&group_id=5470 From noreply at sourceforge.net Tue Oct 21 11:52:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 11:52:51 2003 Subject: [Python-bugs-list] [ python-Bugs-810843 ] Support for non-string data in ConfigParser unclear/buggy Message-ID: Bugs item #810843, was opened at 2003-09-22 17:58 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810843&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: curby (kirbysdl) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Support for non-string data in ConfigParser unclear/buggy Initial Comment: In my current project, I'm using ConfigParser to read configuration files as well as manage internal configuration. The following test script generates an error because values of options must be strings in order for ConfigParser to run smoothly. (It's short enough that I'm including it here for reference; I'm also attaching it). #----- BEGIN TEST ----- #!/usr/bin/env python import ConfigParser import sys conf = ConfigParser.ConfigParser() conf.add_section("sect") conf.set("sect","option",2) conf.write(sys.stderr) conf.get("sect","option") #----- END TEST ----- >From the ConfigParser code, I see that the value isn't checked to make sure it is a string before string methods are applied to it. I'm currently using the raw parameter to get() (see http://www.python.org/doc/lib/ConfigParser-objects.html#l2h-1261) in order to circumvent the problem. I'd suggest one or more of the following: (1) Casting the option to a string explicitly instead of assuming it is a string (this could also be done in the set() method). (2) Checking that the option is a string instead of assuming it is a string. (3) Stating in the documentation that the set() method should only take values of type string. (4) Stating in the documentation that the raw parameter should be used when an option's value might not be of type string (this might be the intended usage, but it isn't made clear). I hope none of these are too difficult to implement, but I understand that this is a noncritical problem. Nonetheless, I was shocked to see what I thought was a straightforward use of ConfigParser throw off errors. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=810843&group_id=5470 From noreply at sourceforge.net Tue Oct 21 11:55:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 11:55:05 2003 Subject: [Python-bugs-list] [ python-Bugs-827260 ] Parameter is misnamed in str.replace documentation. Message-ID: Bugs item #827260, was opened at 2003-10-20 23:53 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827260&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Parameter is misnamed in str.replace documentation. Initial Comment: >>> print str.replace.__doc__ S.replace (old, new[, maxsplit]) -> string Return a copy of string S with all occurrences of substring old replaced by new. If the optional argument maxsplit is given, only the first maxsplit occurrences are replaced. --- Honestly, that optional parameter really shouldn't be called "maxsplit" since there's no splitting going on. Just plain "max" would be better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827260&group_id=5470 From noreply at sourceforge.net Tue Oct 21 12:00:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 12:01:11 2003 Subject: [Python-bugs-list] [ python-Bugs-777884 ] minidom.py -- TypeError: object doesn't support slice assig Message-ID: Bugs item #777884, was opened at 2003-07-25 20:22 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777884&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Lesh (leshmark) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: minidom.py -- TypeError: object doesn't support slice assig Initial Comment: Got the following traceback after upgrading to 2.3c1 Traceback (most recent call last): File "/root/alchemy/scripts/cvs/alchemy/alchemy_menu.py", line 178, in menu_system a=alchemy.Alchemy(name=name,step='alchemy') File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 89, in __init__ self.traverseNodes([self.start_node],exclude_tags=["evaporate","info"]) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 786, in traverseNodes self.traverseNodes(node.childNodes,exclude_tags) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 786, in traverseNodes self.traverseNodes(node.childNodes,exclude_tags) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 786, in traverseNodes self.traverseNodes(node.childNodes,exclude_tags) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 786, in traverseNodes self.traverseNodes(node.childNodes,exclude_tags) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 786, in traverseNodes self.traverseNodes(node.childNodes,exclude_tags) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 786, in traverseNodes self.traverseNodes(node.childNodes,exclude_tags) File "/root/alchemy/scripts/cvs/alchemy/alchemy.py", line 766, in traverseNodes node.normalize() File "/usr/lib/python2.3/xml/dom/minidom.py", line 208, in normalize self.childNodes[:] = L TypeError: object doesn't support slice assignment ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-01 03:00 Message: Logged In: YES user_id=21627 It would definitely help if you could provide more detail on the nature of the failure. E.g. where did the DOM tree come from that Alchemy tries to invoke .normalize on, and what is self.childnodes in the place of the error. If you could instead submit a small example that allows reproduction of the error, that would help as well. ---------------------------------------------------------------------- Comment By: Mark Lesh (leshmark) Date: 2003-08-01 02:20 Message: Logged In: YES user_id=76540 The code worked again after I downgraded to Python 2.2.3. If you like I can replicate in a shorter and includable code snippet (I'd need to pop 2.3 back on my box first though) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-07-27 07:10 Message: Logged In: YES user_id=21627 Are you sure this is a bug in Python, and not in Alchemy? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777884&group_id=5470 From noreply at sourceforge.net Tue Oct 21 12:01:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 12:01:57 2003 Subject: [Python-bugs-list] [ python-Bugs-825810 ] reference to Built-In Types section in file() documentation Message-ID: Bugs item #825810, was opened at 2003-10-17 20:22 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825810&group_id=5470 Category: Documentation Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: ewan (gorku) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: reference to Built-In Types section in file() documentation Initial Comment: The file() documentation in section 2.1 says: Return a new file object (described earlier under Built-in Types) but Built-in Types is the _next_ section; this should probably also be a link ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=825810&group_id=5470 From noreply at sourceforge.net Tue Oct 21 12:52:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 12:52:36 2003 Subject: [Python-bugs-list] [ python-Bugs-818861 ] ConfigParser items() inconsistency Message-ID: Bugs item #818861, was opened at 2003-10-06 16:40 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818861&group_id=5470 Category: Python Library >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: ConfigParser items() inconsistency Initial Comment: The RawConfigParser.items() method returns a list while ConfigParser.items() and SafeConfigParser.items() return generators. This inconsistency within the module is a distraction. Reported by Gordon Williams on python-dev. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-21 12:52 Message: Logged In: YES user_id=3066 Fixed in Lib/ConfigParser.py revisions 1.61 and 1.58.8.3. Documentation updated in Doc/lib/libcfgparser.tex revisions 1.31 and 1.29.16.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818861&group_id=5470 From noreply at sourceforge.net Tue Oct 21 13:43:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 13:43:22 2003 Subject: [Python-bugs-list] [ python-Bugs-823328 ] urllib2 digest auth is broken Message-ID: Bugs item #823328, was opened at 2003-10-14 10:03 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 digest auth is broken Initial Comment: The urllib2 digest auth support is busted. For starters, it's looking for a header 'Authorization' with the auth header in it - the correct header is WWW-Authenticate, according to rfc2617 (and confirmed by the "what does apache do?" test). Even after making this fix, auth is still failing, not sure why yet. I'm not convinced, looking at the code, that it could have _ever_ worked. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-10-21 17:43 Message: Logged In: YES user_id=31392 Reviewing the patch just now. It looks basically good. I realize that the reason you had some much trouble with the code is that it was written against RFC 2069 and tested against some very old version of Apache. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 13:18 Message: Logged In: YES user_id=29957 The following patch gives us a urllib2 that supports digest auth again. I've tested against Apache-2..0.47, if someone wants to suggest another webserver to check with, please let me know. We now support RFC2617-compliant versions of digest auth. I have no idea what the code that was in there was trying to do, but it was broken all over the place - there is no way it would have worked. Note the following limitations: - We are sending a client nonce, but we're not checking the Authentication-Info that's coming back. - qop="auth-int" support is shaky. But apache looks like it doesn't support it properly, anyway. And it's no shakier than it was - algorithm="MD5-sess" isn't properly supported, but then, it wasn't before, either. - the code now has a limit of 5 failures in a row before it bails out . there was no limit previously, so it would recurse until the recursion limit was hit. I can't test the old code, unfortunately, but I _believe_ I've made it work again. It certainly could not have worked as it was. I've also not tested proxy-digest-auth - suggestions for a proxy server to try? Assuming my reading of the RFC is right, it should "just work". ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 12:16 Message: Logged In: YES user_id=29957 Ok, we're not handling the qop=auth style of Digest, as specified in the RFC. I'm working on it now. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 10:12 Message: Logged In: YES user_id=29957 Hm. Looking through comments, it's possible that this used to work with an older, broken, apache digest mode. It certainly fails with 2.0.47... :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 From noreply at sourceforge.net Tue Oct 21 14:07:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 14:07:26 2003 Subject: [Python-bugs-list] [ python-Bugs-823328 ] urllib2 digest auth is broken Message-ID: Bugs item #823328, was opened at 2003-10-14 10:03 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 digest auth is broken Initial Comment: The urllib2 digest auth support is busted. For starters, it's looking for a header 'Authorization' with the auth header in it - the correct header is WWW-Authenticate, according to rfc2617 (and confirmed by the "what does apache do?" test). Even after making this fix, auth is still failing, not sure why yet. I'm not convinced, looking at the code, that it could have _ever_ worked. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-10-21 17:43 Message: Logged In: YES user_id=31392 Reviewing the patch just now. It looks basically good. I realize that the reason you had some much trouble with the code is that it was written against RFC 2069 and tested against some very old version of Apache. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 13:18 Message: Logged In: YES user_id=29957 The following patch gives us a urllib2 that supports digest auth again. I've tested against Apache-2..0.47, if someone wants to suggest another webserver to check with, please let me know. We now support RFC2617-compliant versions of digest auth. I have no idea what the code that was in there was trying to do, but it was broken all over the place - there is no way it would have worked. Note the following limitations: - We are sending a client nonce, but we're not checking the Authentication-Info that's coming back. - qop="auth-int" support is shaky. But apache looks like it doesn't support it properly, anyway. And it's no shakier than it was - algorithm="MD5-sess" isn't properly supported, but then, it wasn't before, either. - the code now has a limit of 5 failures in a row before it bails out . there was no limit previously, so it would recurse until the recursion limit was hit. I can't test the old code, unfortunately, but I _believe_ I've made it work again. It certainly could not have worked as it was. I've also not tested proxy-digest-auth - suggestions for a proxy server to try? Assuming my reading of the RFC is right, it should "just work". ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 12:16 Message: Logged In: YES user_id=29957 Ok, we're not handling the qop=auth style of Digest, as specified in the RFC. I'm working on it now. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 10:12 Message: Logged In: YES user_id=29957 Hm. Looking through comments, it's possible that this used to work with an older, broken, apache digest mode. It certainly fails with 2.0.47... :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 From noreply at sourceforge.net Tue Oct 21 14:14:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 14:14:48 2003 Subject: [Python-bugs-list] [ python-Bugs-812353 ] a Py_DECREF() too much Message-ID: Bugs item #812353, was opened at 2003-09-25 10:23 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812353&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Jeremy Hylton (jhylton) Summary: a Py_DECREF() too much Initial Comment: frameobject.c:PyFrame_FastToLocals() has a Py_DECREF(locals) that shouldn't be done. It didn't get noticed because it is in an unprobable path. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-10-21 18:14 Message: Logged In: YES user_id=31392 Fixed in rev 2.76 of frameobject.c. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-26 05:05 Message: Logged In: YES user_id=80475 Jeremy, this is your code fragment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812353&group_id=5470 From noreply at sourceforge.net Tue Oct 21 14:19:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 14:19:54 2003 Subject: [Python-bugs-list] [ python-Bugs-827209 ] List comprehensions leaking control variable name deprecated Message-ID: Bugs item #827209, was opened at 2003-10-20 19:41 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: List comprehensions leaking control variable name deprecated Initial Comment: According to the email thread starting: http://mail.python.org/pipermail/python-dev/2003- October/039081.html the control variable name in a list comprehension should not be leaked and any use of such a leaked name is deprecated. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-21 14:19 Message: Logged In: YES user_id=593130 The tutorial will also need revision of deletion: 5.1.4 List Comprehensions has this: To make list comprehensions match the behavior of for loops, assignments to the loop variable remain visible outside of the comprehension: >>> x = 100 # this gets overwritten >>> [x**3 for x in range(5)] [0, 1, 8, 27, 64] >>> x # the final value for range(5) 4 ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-21 10:26 Message: Logged In: YES user_id=43607 Actually, this is not different from $ python Python 2.4a0 (#2, Oct 14 2003, 11:28:48) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> for x in []: ... pass ... >>> print x Traceback (most recent call last): File "", line 1, in ? NameError: name 'x' is not defined >>> where x is also undefined after iteraring through an empty list. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-10-21 09:52 Message: Logged In: YES user_id=44345 A good point raised by Michael Hudson is that foo = [x for x in R] print x will fail if R is empty (and x wasn't previously defined). All the more reason to deprecate its usage and suppress the leaking variable. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-10-20 20:04 Message: Logged In: YES user_id=593130 Ref Man 5.2.4 List displays: suggested addition at end. Using leaked 'for ' control variables outside the list display is deprecated and will not work when the bug is fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827209&group_id=5470 From noreply at sourceforge.net Tue Oct 21 15:52:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 15:52:37 2003 Subject: [Python-bugs-list] [ python-Bugs-814266 ] new.function raises TypeError for some strange reason... Message-ID: Bugs item #814266, was opened at 2003-09-29 01:31 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814266&group_id=5470 >Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Fincher (jemfinch) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: new.function raises TypeError for some strange reason... Initial Comment: Here's an example pasted directly from the interpreter: >>> def thread(f): ... """Makes sure a command spawns a thread when called.""" ... def newf(self, irc, msg, args, *L): ... ff = new.instancemethod(f, self, self.__class__) ... t = callbacks.CommandThread(self.callCommand, ff, irc, msg, args, *L) ... t.start() ... newf = new.function(newf.func_code, newf.func_globals, f.func_name) ... newf.__doc__ = f.__doc__ ... return newf ... >>> import new >>> def groovy(): ... pass ... >>> thread(groovy) Traceback (most recent call last): File "", line 1, in ? File "", line 7, in thread TypeError: arg 5 (closure) must be tuple Given that I didn't even give the (optional) arg 5, there's some bug here, even if it's only documentation/error message. ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-21 15:52 Message: Logged In: YES user_id=99508 Ok, I finally found my problem -- I wasn't passing the closure=newf.func_closure argument to it. Anyway, this is a significant documentation bug, I think -- aside from the fact that the library documentation isn't inline with the __doc__ string, it should be documented that the closure argument is required if the func_code depends on a closure. Check this out: >>> print new.function.__doc__ function(code, globals[, name[, argdefs[, closure]]]) Create a function object from a code object and a dictionary. The optional name string overrides the name from the code object. The optional argdefs tuple specifies the default argument values. The optional closure tuple supplies the bindings for free variables. Versus the library documentation: function( code, globals[, name[, argdefs]]) Returns a (Python) function with the given code and globals. If name is given, it must be a string or None. If it is a string, the function will have the given name, otherwise the function name will be taken from code.co_name. If argdefs is given, it must be a tuple and will be used to determine the default values of parameters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=814266&group_id=5470 From noreply at sourceforge.net Tue Oct 21 16:05:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 16:06:08 2003 Subject: [Python-bugs-list] [ python-Bugs-827760 ] Bug in dbm - long strings in keys and values Message-ID: Bugs item #827760, was opened at 2003-10-21 13: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=827760&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Draper (jdcrunchman) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in dbm - long strings in keys and values Initial Comment: #!/usr/local/bin/python #2003-10-19. Feedback to crunch@shopip.com import dbm print """ Python dbm bugs summary: 1. Long strings cause weirdness. 2. Long keys fail without returning error. This demonstrates serious bugs in the Python dbm module. Present in OpenBSD versions 2.2, 2.3, and 2.3.2c1. len(key+string)>61231 results in the item being 'lost', without warning. If the key or string is one character shorter, it is fine. Writing multiple long strings causes unpredictable results (none, some, or all of the items are lost without warning). Curiously, keys of length 57148 return an error, but longer keys fail without warning (sounds like an = instead of a > somewhere). """ mdb=dbm.open("mdb","n") print "Writing 1 item to database, but upon reading," k='k' v='X'*61230 #Long string mdb[k]=v mdb.close() md=dbm.open("mdb","r") print "database contains %i items"%len(md.keys()) md.close() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827760&group_id=5470 From noreply at sourceforge.net Tue Oct 21 18:47:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 18:48:05 2003 Subject: [Python-bugs-list] [ python-Bugs-827856 ] object.h misdocuments PyDict_SetItemString Message-ID: Bugs item #827856, was opened at 2003-10-21 14: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=827856&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: object.h misdocuments PyDict_SetItemString Initial Comment: I just happened to notice the following in the comment titled "Reference Counts" toward the end of object.h (2.3.2): Functions that 'store' objects such as PyTuple_SetItem () and PyDict_SetItemString() don't increment the reference count of the object I believe PyDict_SetItemString does increment the refcount. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827856&group_id=5470 From noreply at sourceforge.net Tue Oct 21 20:32:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 20:32:09 2003 Subject: [Python-bugs-list] [ python-Bugs-827902 ] ctime is not creation time Message-ID: Bugs item #827902, was opened at 2003-10-22 02: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=827902&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: ctime is not creation time Initial Comment: Hi! http://python.org/doc/current/lib/module-os.path.html says getctime() returns the creation time. But it probably returns the ctime, which has nothing to do with creation. Bye, Robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 From noreply at sourceforge.net Tue Oct 21 22:59:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 23:23:24 2003 Subject: [Python-bugs-list] [ python-Bugs-827260 ] Parameter is misnamed in str.replace documentation. Message-ID: Bugs item #827260, was opened at 2003-10-20 23:53 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827260&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Parameter is misnamed in str.replace documentation. Initial Comment: >>> print str.replace.__doc__ S.replace (old, new[, maxsplit]) -> string Return a copy of string S with all occurrences of substring old replaced by new. If the optional argument maxsplit is given, only the first maxsplit occurrences are replaced. --- Honestly, that optional parameter really shouldn't be called "maxsplit" since there's no splitting going on. Just plain "max" would be better. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-10-21 22:59 Message: Logged In: YES user_id=3066 Agreed; I've changed the parameter name to simply "count". Fixed in Objects/stringobject.c revisions 2.212 and 2.209, Doc/lib/libstdtypes.tex revisions 1.138 and 1.129.8.7. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827260&group_id=5470 From noreply at sourceforge.net Tue Oct 21 22:54:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 23:23:41 2003 Subject: [Python-bugs-list] [ python-Bugs-827963 ] Registry key CurrentVersion not set Message-ID: Bugs item #827963, was opened at 2003-10-21 21: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=827963&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Jimm Domingo (jimm_domingo) Assigned to: Thomas Heller (theller) Summary: Registry key CurrentVersion not set Initial Comment: According to the documentation for Python's use of the Windows registry, the version number of most recently installed version is in the key HKEY_LOCAL_MACHINE\Software\Python\PythonCore\CurrentVersion. But this key does not exist on my system. My configuration: Python 2.2.3 (#42, May 30 2003, 18:12:08) on Windows XP Professional, Version 2002, SP1. FWIW, I downloaded most recent revision (1.133.4.4) of the Wise installation script (python20.wse) from CVS. I then opened it with an evaluation copy of Wise Installation System. I've never used that product, but it appears that the above key isn't assigned a value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827963&group_id=5470 From noreply at sourceforge.net Tue Oct 21 23:38:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 21 23:38:53 2003 Subject: [Python-bugs-list] [ python-Bugs-823328 ] urllib2 digest auth is broken Message-ID: Bugs item #823328, was opened at 2003-10-14 20:03 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 digest auth is broken Initial Comment: The urllib2 digest auth support is busted. For starters, it's looking for a header 'Authorization' with the auth header in it - the correct header is WWW-Authenticate, according to rfc2617 (and confirmed by the "what does apache do?" test). Even after making this fix, auth is still failing, not sure why yet. I'm not convinced, looking at the code, that it could have _ever_ worked. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 13:38 Message: Logged In: YES user_id=29957 I think this should be backported to 2.3, as well - it's a fix of the currently busted code. You agree with this, Jeremy? (The note about the need for tests is known, btw, I'm working on the server side of http digest auth) ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-10-22 03:43 Message: Logged In: YES user_id=31392 Reviewing the patch just now. It looks basically good. I realize that the reason you had some much trouble with the code is that it was written against RFC 2069 and tested against some very old version of Apache. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 23:18 Message: Logged In: YES user_id=29957 The following patch gives us a urllib2 that supports digest auth again. I've tested against Apache-2..0.47, if someone wants to suggest another webserver to check with, please let me know. We now support RFC2617-compliant versions of digest auth. I have no idea what the code that was in there was trying to do, but it was broken all over the place - there is no way it would have worked. Note the following limitations: - We are sending a client nonce, but we're not checking the Authentication-Info that's coming back. - qop="auth-int" support is shaky. But apache looks like it doesn't support it properly, anyway. And it's no shakier than it was - algorithm="MD5-sess" isn't properly supported, but then, it wasn't before, either. - the code now has a limit of 5 failures in a row before it bails out . there was no limit previously, so it would recurse until the recursion limit was hit. I can't test the old code, unfortunately, but I _believe_ I've made it work again. It certainly could not have worked as it was. I've also not tested proxy-digest-auth - suggestions for a proxy server to try? Assuming my reading of the RFC is right, it should "just work". ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 22:16 Message: Logged In: YES user_id=29957 Ok, we're not handling the qop=auth style of Digest, as specified in the RFC. I'm working on it now. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-14 20:12 Message: Logged In: YES user_id=29957 Hm. Looking through comments, it's possible that this used to work with an older, broken, apache digest mode. It certainly fails with 2.0.47... :-( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823328&group_id=5470 From noreply at sourceforge.net Wed Oct 22 03:57:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 03:57:46 2003 Subject: [Python-bugs-list] [ python-Bugs-828049 ] Idle fails on loading .idlerc if Home path changes. Message-ID: Bugs item #828049, was opened at 2003-10-22 09:57 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=828049&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Frithiof Andreas Jensen (fajensen) Assigned to: Nobody/Anonymous (nobody) Summary: Idle fails on loading .idlerc if Home path changes. Initial Comment: I have a Windows laptop. Normally it resides in a docking station, meaing my Home directory is referenced from a network drive labelled 'H:' When I Eject the labtop my home directory by scripted magick becomes referenced off 'C:' If I have Idle running already and start a new Idle window, the new window will fail, raising a FileError exception over not finding the '.idlerc' at 'H:' - which it cannot because it disapeared. If I do not have Idle running and start it after undocking, it will fail silently never bringing up a window. I suspect for the same reason: The home drive changes but the change is not reflected in the information available to Python/Idle. Maybe it is possible to search for a valid path when the first (cached?) attempt fails - or maybe a workaround could be to raise a Warning instead of an Exception, letting the user decide? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828049&group_id=5470 From noreply at sourceforge.net Wed Oct 22 04:00:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 04:00:29 2003 Subject: [Python-bugs-list] [ python-Bugs-828050 ] Solaris tar doesn't like Python-2.3.2.tar.gz Message-ID: Bugs item #828050, was opened at 2003-10-22 10: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=828050&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris tar doesn't like Python-2.3.2.tar.gz Initial Comment: Sun's tar on Solaris 8 and 9 cannot expand Python -2.3.2.tar.gz: $ gunzip < Python-2.3.2.tar.gz | tar xf - tar: directory checksum error GNU tar doesn't have that problem, but needs to be installed seperately. uname -a for the systems I tested: - SunOS mai-ambessa 5.8 Generic_108528-03 sun4u sparc SUNW,Ultra-60 - SunOS gironde 5.9 Generic sun4u sparc SUNW,Ultra-5_10 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828050&group_id=5470 From noreply at sourceforge.net Wed Oct 22 04:10:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 04:11:15 2003 Subject: [Python-bugs-list] [ python-Bugs-828050 ] Solaris tar doesn't like Python-2.3.2.tar.gz Message-ID: Bugs item #828050, was opened at 2003-10-22 18:00 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828050&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris tar doesn't like Python-2.3.2.tar.gz Initial Comment: Sun's tar on Solaris 8 and 9 cannot expand Python -2.3.2.tar.gz: $ gunzip < Python-2.3.2.tar.gz | tar xf - tar: directory checksum error GNU tar doesn't have that problem, but needs to be installed seperately. uname -a for the systems I tested: - SunOS mai-ambessa 5.8 Generic_108528-03 sun4u sparc SUNW,Ultra-60 - SunOS gironde 5.9 Generic sun4u sparc SUNW,Ultra-5_10 ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-22 18:10 Message: Logged In: YES user_id=29957 This is documented on the Build bugs section of the 2.3.2 webpages (http://www.python.org/2.3.2/bugs.html#build). It's not something I plan to do anything about - the ancient tar shipped on platforms such as Solaris is beyond help. The appropriate fix is to get Sun to ship a newer tar. Or simply download gnutar - packages are available from, e.g. www.sunfreeware.com. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828050&group_id=5470 From noreply at sourceforge.net Wed Oct 22 09:49:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 09:49:43 2003 Subject: [Python-bugs-list] [ python-Bugs-758241 ] asyncore with non-default map problems Message-ID: Bugs item #758241, was opened at 2003-06-20 21:41 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758241&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bob Halley (rthalley) Assigned to: A.M. Kuchling (akuchling) Summary: asyncore with non-default map problems Initial Comment: When you use asyncore with a non-default map, methods of the dispatcher object break. E.g. if you close() the object, it tries to remove itself from the default map, not from the map the dispatcher was created with. There should be a map instance variable that contains the map the object was created with, and it should be used whenever the map needs to be referenced, e.g. in add_channel/del_channel. This would make close work correctly again. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-10-22 09:49 Message: Logged In: YES user_id=11375 Applied to the CVS trunk as rev 1.42 of asyncore.py. Thanks to both of you for the patch, and for reporting the bug. ---------------------------------------------------------------------- Comment By: Stephane Ninin (stephane_ninin) Date: 2003-09-29 10:51 Message: Logged In: YES user_id=874382 I think this should solve the problem with non-default maps in asyncore.dispatcher. Hope this helps. *** asyncore.py Mon Sep 29 16:20:13 2003 --- asyncore-new.py Mon Sep 29 16:20:26 2003 *************** *** 201,206 **** --- 201,211 ---- addr = None def __init__(self, sock=None, map=None): + if (map is None): + self.map = socket_map + else: + self.map=map + if sock: self.set_socket(sock, map) # I think it should inherit this anyway *************** *** 248,254 **** self.socket = socket.socket(family, type) self.socket.setblocking(0) self._fileno = self.socket.fileno() ! self.add_channel() def set_socket(self, sock, map=None): self.socket = sock --- 253,259 ---- self.socket = socket.socket(family, type) self.socket.setblocking(0) self._fileno = self.socket.fileno() ! self.add_channel(self.map) def set_socket(self, sock, map=None): self.socket = sock *************** *** 353,359 **** raise socket.error, why def close(self): ! self.del_channel() self.socket.close() # cheap inheritance, used to pass all other attribute --- 358,364 ---- raise socket.error, why def close(self): ! self.del_channel(self.map) self.socket.close() # cheap inheritance, used to pass all other attribute ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=758241&group_id=5470 From noreply at sourceforge.net Wed Oct 22 10:12:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 10:12:44 2003 Subject: [Python-bugs-list] [ python-Bugs-809174 ] xmlrpclib's functions dumps() and loads() not documented. Message-ID: Bugs item #809174, was opened at 2003-09-19 05:41 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809174&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Arsalan Zaidi (azaidi) Assigned to: A.M. Kuchling (akuchling) Summary: xmlrpclib's functions dumps() and loads() not documented. Initial Comment: The documentation does not appear for these two (more?) functions in the python library reference... I wouldn't have found them were it not for an article on XML-RPC. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-10-22 10:12 Message: Logged In: YES user_id=11375 Thank you for pointing this out; I've just documented the two functions in the 2.4 CVS tree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809174&group_id=5470 From noreply at sourceforge.net Wed Oct 22 12:02:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 12:03:27 2003 Subject: [Python-bugs-list] [ python-Bugs-827902 ] ctime is not creation time Message-ID: Bugs item #827902, was opened at 2003-10-22 02:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: ctime is not creation time Initial Comment: Hi! http://python.org/doc/current/lib/module-os.path.html says getctime() returns the creation time. But it probably returns the ctime, which has nothing to do with creation. Bye, Robert ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-22 18:02 Message: Logged In: YES user_id=21627 Why do you say ctime has nothing to do with creation? What else does ctime indicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 From noreply at sourceforge.net Wed Oct 22 14:26:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 14:26:26 2003 Subject: [Python-bugs-list] [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 05:21 Message generated for change (Comment added) made by billbaxter26 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: Later Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) 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: Bill Baxter (billbaxter26) Date: 2003-10-22 14: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 07: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 #include #include #include 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 08: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 03: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 14: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 09: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 09: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 20: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 18:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" To: "Ralf W. Grosse-Kunstleve" 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 #include . . . 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 10: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 02: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 19: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 13: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 14: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 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 08: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 Wed Oct 22 15:30:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 15:30:49 2003 Subject: [Python-bugs-list] [ python-Bugs-828450 ] sdist generates bad MANIFEST on Windows Message-ID: Bugs item #828450, was opened at 2003-10-22 19: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=828450&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) Assigned to: Nobody/Anonymous (nobody) Summary: sdist generates bad MANIFEST on Windows Initial Comment: The generated MANIFEST file has Windows slashes separating path components. If you use this MANIFEST on Unix, it will bomb complaining the the files are not "regular files." If you generate a MANIFEST on Unix, it will work on Windows. Presumably the solution is to replace \ with / on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828450&group_id=5470 From noreply at sourceforge.net Wed Oct 22 17:14:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 17:14:36 2003 Subject: [Python-bugs-list] [ python-Bugs-827902 ] ctime is not creation time Message-ID: Bugs item #827902, was opened at 2003-10-22 02:32 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: ctime is not creation time Initial Comment: Hi! http://python.org/doc/current/lib/module-os.path.html says getctime() returns the creation time. But it probably returns the ctime, which has nothing to do with creation. Bye, Robert ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-22 23:14 Message: Logged In: YES user_id=43607 ctime is change time. Read the manual (stat(2)): time_t st_atime; /* time of last access */ time_t st_mtime; /* time of last modification */ time_t st_ctime; /* time of last change */ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-22 18:02 Message: Logged In: YES user_id=21627 Why do you say ctime has nothing to do with creation? What else does ctime indicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 From noreply at sourceforge.net Wed Oct 22 18:11:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 18:12:16 2003 Subject: [Python-bugs-list] [ python-Bugs-827902 ] ctime is not creation time Message-ID: Bugs item #827902, was opened at 2003-10-22 02:32 Message generated for change (Comment added) made by siemer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: ctime is not creation time Initial Comment: Hi! http://python.org/doc/current/lib/module-os.path.html says getctime() returns the creation time. But it probably returns the ctime, which has nothing to do with creation. Bye, Robert ---------------------------------------------------------------------- >Comment By: Robert Siemer (siemer) Date: 2003-10-23 00:11 Message: Logged In: YES user_id=150699 ctime is the time of last modification of file status information. Means: gets updated on everything... (-: There is no way on classic Linux-Filesystems to get the creation time. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-22 23:14 Message: Logged In: YES user_id=43607 ctime is change time. Read the manual (stat(2)): time_t st_atime; /* time of last access */ time_t st_mtime; /* time of last modification */ time_t st_ctime; /* time of last change */ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-22 18:02 Message: Logged In: YES user_id=21627 Why do you say ctime has nothing to do with creation? What else does ctime indicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 From noreply at sourceforge.net Wed Oct 22 22:19:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 22 22:19:55 2003 Subject: [Python-bugs-list] [ 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: Later Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) 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: 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 #include #include #include 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" To: "Ralf W. Grosse-Kunstleve" 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 #include . . . 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 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 Oct 23 04:03:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 04:05:49 2003 Subject: [Python-bugs-list] [ python-Bugs-828737 ] unicode translate leaks memory Message-ID: Bugs item #828737, was opened at 2003-10-23 10: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=828737&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Nobody/Anonymous (nobody) Summary: unicode translate leaks memory Initial Comment: (Python 2.3.2, running on Windows 2K) this program needs over 100 megabytes (and lots of CPU time) for n=10, and runs out of memory for n=100. charmap = { ord("&"): u"&", ord("<"): u"<", ord(">"): u">", ord('"'): u""", } for n in (1, 10, 100, 1000): text = u'abcghi'*n print n, len(text) print text.translate(charmap) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828737&group_id=5470 From noreply at sourceforge.net Thu Oct 23 04:14:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 04:15:09 2003 Subject: [Python-bugs-list] [ python-Bugs-827902 ] ctime is not creation time Message-ID: Bugs item #827902, was opened at 2003-10-22 02:32 Message generated for change (Comment added) made by johahn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: ctime is not creation time Initial Comment: Hi! http://python.org/doc/current/lib/module-os.path.html says getctime() returns the creation time. But it probably returns the ctime, which has nothing to do with creation. Bye, Robert ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-23 10:14 Message: Logged In: YES user_id=887415 On Windows 2000 os.path.ctime (-> ntpath.getctime -> ntpath.stat.st_ctime) returns creation time. ---------------------------------------------------------------------- Comment By: Robert Siemer (siemer) Date: 2003-10-23 00:11 Message: Logged In: YES user_id=150699 ctime is the time of last modification of file status information. Means: gets updated on everything... (-: There is no way on classic Linux-Filesystems to get the creation time. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-22 23:14 Message: Logged In: YES user_id=43607 ctime is change time. Read the manual (stat(2)): time_t st_atime; /* time of last access */ time_t st_mtime; /* time of last modification */ time_t st_ctime; /* time of last change */ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-22 18:02 Message: Logged In: YES user_id=21627 Why do you say ctime has nothing to do with creation? What else does ctime indicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 From noreply at sourceforge.net Thu Oct 23 04:19:20 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 04:19:28 2003 Subject: [Python-bugs-list] [ python-Bugs-828743 ] bdist_rpm failure when no setup.py Message-ID: Bugs item #828743, was opened at 2003-10-23 11: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=828743&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm failure when no setup.py Initial Comment: Hi, It appeas that setup.py is hardcoded into bdist_rpm.py and this causes failure whenever using setup.py with a different name. For example: python setup_xxx.py bdist_rpm results in + env 'CFLAGS=-O2 -march=i386 -mcpu=i686' python setup.py build python: can't open file 'setup.py' error: Bad exit status from /var/tmp/rpm-tmp.14535 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.14535 (%build) error: command 'rpmbuild' failed with exit status 1 Would it be possible for bdist_rpm.py to use the same setup.py filename in def_build variable that called it? Pearu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828743&group_id=5470 From noreply at sourceforge.net Thu Oct 23 06:25:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 06:25:40 2003 Subject: [Python-bugs-list] [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 10:21 Message generated for change (Comment added) made by mwh 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: Later Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) 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: Michael Hudson (mwh) Date: 2003-10-23 11: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 03: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 19: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 12: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 #include #include #include 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 13: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 08: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 19: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 14: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 14: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 01: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 23:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" To: "Ralf W. Grosse-Kunstleve" 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 #include . . . 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 15: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 07: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 00: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 18: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 19: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 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 13: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 Oct 23 07:39:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 07:40:37 2003 Subject: [Python-bugs-list] [ python-Bugs-828737 ] unicode translate leaks memory Message-ID: Bugs item #828737, was opened at 2003-10-23 10:03 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828737&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Fredrik Lundh (effbot) >Assigned to: Walter D?rwald (doerwalter) Summary: unicode translate leaks memory Initial Comment: (Python 2.3.2, running on Windows 2K) this program needs over 100 megabytes (and lots of CPU time) for n=10, and runs out of memory for n=100. charmap = { ord("&"): u"&", ord("<"): u"<", ord(">"): u">", ord('"'): u""", } for n in (1, 10, 100, 1000): text = u'abcghi'*n print n, len(text) print text.translate(charmap) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-10-23 13:39 Message: Logged In: YES user_id=89016 That looks like a bug with the exponential reallocation in unicodeobject.c/charmaptranslate_makespace(). I'm on it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828737&group_id=5470 From noreply at sourceforge.net Thu Oct 23 08:17:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 08:17:41 2003 Subject: [Python-bugs-list] [ python-Bugs-828450 ] sdist generates bad MANIFEST on Windows Message-ID: Bugs item #828450, was opened at 2003-10-22 15:30 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828450&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jeremy Hylton (jhylton) >Assigned to: A.M. Kuchling (akuchling) Summary: sdist generates bad MANIFEST on Windows Initial Comment: The generated MANIFEST file has Windows slashes separating path components. If you use this MANIFEST on Unix, it will bomb complaining the the files are not "regular files." If you generate a MANIFEST on Unix, it will work on Windows. Presumably the solution is to replace \ with / on Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828450&group_id=5470 From noreply at sourceforge.net Thu Oct 23 08:17:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 08:17:48 2003 Subject: [Python-bugs-list] [ python-Bugs-828743 ] bdist_rpm failure when no setup.py Message-ID: Bugs item #828743, was opened at 2003-10-23 04:19 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828743&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) >Assigned to: A.M. Kuchling (akuchling) Summary: bdist_rpm failure when no setup.py Initial Comment: Hi, It appeas that setup.py is hardcoded into bdist_rpm.py and this causes failure whenever using setup.py with a different name. For example: python setup_xxx.py bdist_rpm results in + env 'CFLAGS=-O2 -march=i386 -mcpu=i686' python setup.py build python: can't open file 'setup.py' error: Bad exit status from /var/tmp/rpm-tmp.14535 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.14535 (%build) error: command 'rpmbuild' failed with exit status 1 Would it be possible for bdist_rpm.py to use the same setup.py filename in def_build variable that called it? Pearu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828743&group_id=5470 From noreply at sourceforge.net Thu Oct 23 08:44:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 08:44:56 2003 Subject: [Python-bugs-list] [ python-Bugs-828890 ] bdist_rpm failure when no setup.py Message-ID: Bugs item #828890, was opened at 2003-10-23 15: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=828890&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Pearu Peterson (pearu) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm failure when no setup.py Initial Comment: Hi, It appeas that setup.py is hardcoded into bdist_rpm.py and this causes failure whenever using setup.py with a different name. For example: python setup_xxx.py bdist_rpm results in + env 'CFLAGS=-O2 -march=i386 -mcpu=i686' python setup.py build python: can't open file 'setup.py' error: Bad exit status from /var/tmp/rpm-tmp.14535 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.14535 (%build) error: command 'rpmbuild' failed with exit status 1 Would it be possible for bdist_rpm.py to use the same setup.py filename in def_build variable that called it? Pearu ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828890&group_id=5470 From noreply at sourceforge.net Thu Oct 23 09:15:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 09:15:23 2003 Subject: [Python-bugs-list] [ python-Bugs-828890 ] bdist_rpm failure when no setup.py Message-ID: Bugs item #828890, was opened at 2003-10-23 08:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828890&group_id=5470 Category: Distutils Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Pearu Peterson (pearu) Assigned to: Nobody/Anonymous (nobody) Summary: bdist_rpm failure when no setup.py Initial Comment: Hi, It appeas that setup.py is hardcoded into bdist_rpm.py and this causes failure whenever using setup.py with a different name. For example: python setup_xxx.py bdist_rpm results in + env 'CFLAGS=-O2 -march=i386 -mcpu=i686' python setup.py build python: can't open file 'setup.py' error: Bad exit status from /var/tmp/rpm-tmp.14535 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.14535 (%build) error: command 'rpmbuild' failed with exit status 1 Would it be possible for bdist_rpm.py to use the same setup.py filename in def_build variable that called it? Pearu ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-23 09:15 Message: Logged In: YES user_id=33168 Duplicate of 828743 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828890&group_id=5470 From noreply at sourceforge.net Thu Oct 23 12:02:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 12:02:44 2003 Subject: [Python-bugs-list] [ python-Bugs-811082 ] test_tempfile fails on windows if space in install path Message-ID: Bugs item #811082, was opened at 2003-09-23 12:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811082&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: test_tempfile fails on windows if space in install path Initial Comment: test_tempfile fails for me on XP when Python is installed into \Program Files\Python2.3 I can't cut'n'paste from the window, but the error is C:\Program: Can't open file 'Files\Python23\python.exe' from test_tempfile, line 299. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-23 18:02 Message: Logged In: YES user_id=21627 Fixed with said patch. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-09-26 20:01 Message: Logged In: YES user_id=31511 Submitted patch #813200 to fix this issue. Please review and apply if correct. ---------------------------------------------------------------------- Comment By: Michael Bartl (midramas) Date: 2003-09-26 15:19 Message: Logged In: YES user_id=31511 I'm not at home so I have to paste it in here (could provide a patch later). Took me ~2 hours to fix this one (horrible win32). For more information visit http://mail.python.org/pipermail/python-dev/2003- August/037556.html: test_tempfile.py (295-297): decorated = '"%s"' % sys.executable tester = '"%s"' % tester retval = os.spawnl(os.P_WAIT, sys.executable, decorated, tester, v, fd) ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-23 12:44 Message: Logged In: YES user_id=29957 Attempting the obvious fix of " " quoting sys.executable gives me a Invalid argument error from os.spawnv, so that's my windows knowledge exhausted. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-09-23 12:36 Message: Logged In: YES user_id=29957 test_popen seems to have the same problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811082&group_id=5470 From noreply at sourceforge.net Thu Oct 23 13:53:03 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 13:53:09 2003 Subject: [Python-bugs-list] [ python-Bugs-700780 ] ncurses/curses on solaris Message-ID: Bugs item #700780, was opened at 2003-03-10 06:54 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Iain Morrison (iainmorrison) Assigned to: A.M. Kuchling (akuchling) Summary: ncurses/curses on solaris Initial Comment: solaris 8 [sparc] gcc 3.2.2 python 2.2.2 I am having trouble with curses support. ncurses 5.3 is installed in the standard solaris manner ** Configuration summary for NCURSES 5.3 20021012: bin directory: /usr/local/bin lib directory: /usr/local/lib include directory: /usr/local/include/ncurses man directory: /usr/local/man terminfo directory: /usr/local/share/terminfo ** Include-directory is not in a standard location is not picked up by ./configure. checking for ncurses.h... no Python builds fine but ./python ./Lib/test/test_curses.py -u curses Traceback (most recent call last): File "./Lib/test/test_curses.py", line 11, in ? import curses, sys, tempfile File "/usr/local/src/python/Python-2.2.2/Lib/curses/__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses I'm doing something wrong but I'm nor sure what. Do I need to have ncurses overwrite the default Solaris curses? If so will anything break? many thanks iain morrison iain.morrison@mrc-cbu.cam.ac.uk ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-10-23 13:53 Message: Logged In: YES user_id=11375 No response to query in six months; closing the bug. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-30 11:18 Message: Logged In: YES user_id=21627 What is the ncurses portion of running setup.py? ---------------------------------------------------------------------- Comment By: Iain Morrison (iainmorrison) Date: 2003-03-25 11:11 Message: Logged In: YES user_id=720523 Using setenv CPPFLAGS -I/usr/local/include/ncurses and running ./configure I get checking for ncurses.h... yes However the Makefile is identival to that produced without CPPFLAGS set. The curses test still fails 178 tests OK. 15 tests skipped: test_al test_bsddb test_cd test_cl test_curses test_dl test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_openpty test_winreg test_winsound ./python ./Lib/test/test_curses.py -u curses Traceback (most recent call last): File "./Lib/test/test_curses.py", line 11, in ? import curses, sys, tempfile File "/usr/local/src/python/Python-2.2.2-test/Lib/curses/__init__.py", line 15, in ? from _curses import * ImportError: No module named _curses diff configure-output ../Python-2.2.2/configure-output 39c39 < checking for ncurses.h... yes --- > checking for ncurses.h... no diff Makefile ../Python-2.2.2/Makefile Anything else I can try iain ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-03-15 08:44 Message: Logged In: YES user_id=21627 Did you expect to use ncurses, or did you mean to use curses? What is the ncurses portion of running setup.py? To eliminate setup.py problems, you can always edit Modules/Setup. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-03-14 10:45 Message: Logged In: YES user_id=11375 Your compiler may not be looking in /usr/local/ for headers and libraries. You shouldn't install ncurses over Solaris curses; locally-installed software belongs in /usr/local/, period. When you run the configure script, you can supply environment variables to add compiler flags; run configure --help to see a list. I'd suggest something like 'CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib ./configure', and see if it picks up ncurses.h then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700780&group_id=5470 From noreply at sourceforge.net Thu Oct 23 13:56:59 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 13:57:03 2003 Subject: [Python-bugs-list] [ python-Bugs-665572 ] missing important curses calls Message-ID: Bugs item #665572, was opened at 2003-01-10 04:36 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665572&group_id=5470 Category: Python Library >Group: Feature Request >Status: Closed >Resolution: Later Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: A.M. Kuchling (akuchling) Summary: missing important curses calls Initial Comment: [ submitted to http://bugs.debian.org/175590 ] The curses library is missing two important calls: newterm() -- required to work with multiple terminals, or to find out if it is possible to work with this terminal delscreen() -- required to free up the memory after endwin() -- current implementations have memory leaks for programs that need to start and stop (those that handle terminal resizes, for instance) ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-10-23 13:56 Message: Logged In: YES user_id=11375 Adding to the feature request list and closing the bug. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-08-13 19:30 Message: Logged In: YES user_id=11375 Would anyone care to submit a patch to add the missing calls? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=665572&group_id=5470 From noreply at sourceforge.net Thu Oct 23 22:44:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 23 22:44:28 2003 Subject: [Python-bugs-list] [ python-Feature Requests-829370 ] math.signum(int) Message-ID: Feature Requests item #829370, was opened at 2003-10-24 04:44 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=829370&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Konrad Voelkel (gekonntde) Assigned to: Nobody/Anonymous (nobody) Summary: math.signum(int) Initial Comment: python needs a signum function, def signum(self, int): if(int < 0): return -1; elif(int > 0): return 1; else: return int; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=829370&group_id=5470 From noreply at sourceforge.net Fri Oct 24 03:53:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 24 03:54:02 2003 Subject: [Python-bugs-list] [ python-Bugs-829458 ] setattr(obj, BADNAME, value) does not raises exception Message-ID: Bugs item #829458, was opened at 2003-10-24 11: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=829458&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: setattr(obj, BADNAME, value) does not raises exception Initial Comment: Now I just realize that setattr() does not check value of the name argument but simply insert the named value in __dict__ so setattr(obj, BADNAME, value) not equal to obj.BADNAME = value. It's true for new and old style classes and all python versions which I have tried (1.5, 2.1, 2.2, 2.3). Should not setattr(obj, BADNAME, value) raise appropriate exception (AttributeError or maybe ValueError)? For example: >>> class Test: pass ... >>> o = Test() >>> setattr(o, "test.test", 100) >>> setattr(o, "12345", 200) >>> dir(o) ['12345', '__doc__', '__module__', 'test.test'] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 From noreply at sourceforge.net Fri Oct 24 07:44:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 24 07:44:11 2003 Subject: [Python-bugs-list] [ python-Bugs-829532 ] os.makedirs() cannot handle "." Message-ID: Bugs item #829532, was opened at 2003-10-24 13: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=829532&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs() cannot handle "." Initial Comment: Invoking os.makedirs() with an argument that contains a directory name with a single dot fails. The resulting error is confusing: "File exists". The problem is that the path is split up in pieces and an attempt is made to create the "." directory. This always exists, of course. It happens anyway, because the test for existence is done before creating the directory that contains ".". There are various possible solutions: 1. First normalize the path so that "." entries are removed. This would also work for ".." entries. But it might cause trouble for symbolic links and there is a performance penalty. 2. Check for existence of the directory again after the recursive call to create the directory that contains the entry. This will cause the normal error for an existing directory to be skipped, unless an extra flag is added. This gets complicated. 3. Simply skip creating a directory with the name ".". I propose to use the third solution. I have attached a patch for this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 From noreply at sourceforge.net Fri Oct 24 09:51:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 24 09:51:58 2003 Subject: [Python-bugs-list] [ python-Feature Requests-793798 ] Redirect file output into variables Message-ID: Feature Requests item #793798, was opened at 2003-08-23 17:52 Message generated for change (Comment added) made by elfring You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793798&group_id=5470 Category: Python Library Group: None >Status: Open Resolution: Works For Me Priority: 5 Submitted By: Markus Elfring (elfring) >Assigned to: Martin v. L?wis (loewis) Summary: Redirect file output into variables Initial Comment: The PHP programming language provides output control functions (http://de.php.net/manual/en/ref.outcontrol.php, e. g. "ob_get_contents"). I am looking for similar functionality to use with phyton. 1. I suggest to add a parameter that specifies a variable name. open(file, flags[, mode[, variable name]]) fdopen(fd[, mode[, bufsize[, variable name]]]) 2. Another technique is to implement a virtual file system that converts variables into special files. Has anybody tried to create a file system interface for variables before? A code example can be found with a similar feature request for TCL. https://sourceforge.net/tracker/?func=detail&aid=792990&group_id=10894&atid=360894 ---------------------------------------------------------------------- >Comment By: Markus Elfring (elfring) Date: 2003-10-24 15:51 Message: Logged In: YES user_id=572001 I can not see by the description "http://www.python.org/doc/current/lib/module- StringIO.html" how STDOUT (http://www.python.org/doc/current/lib/os-fd-ops.html) can be redirected. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-20 23:09 Message: Logged In: YES user_id=21627 This is already available. StringIO/cStringIO allow readily to output streams into memory. Use it like this variable = cStringIO.StringIO() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793798&group_id=5470 From noreply at sourceforge.net Fri Oct 24 11:05:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 24 11:06:00 2003 Subject: [Python-bugs-list] [ python-Bugs-828737 ] unicode translate leaks memory Message-ID: Bugs item #828737, was opened at 2003-10-23 10:03 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828737&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Fredrik Lundh (effbot) Assigned to: Walter D?rwald (doerwalter) Summary: unicode translate leaks memory Initial Comment: (Python 2.3.2, running on Windows 2K) this program needs over 100 megabytes (and lots of CPU time) for n=10, and runs out of memory for n=100. charmap = { ord("&"): u"&", ord("<"): u"<", ord(">"): u">", ord('"'): u""", } for n in (1, 10, 100, 1000): text = u'abcghi'*n print n, len(text) print text.translate(charmap) ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2003-10-24 17:05 Message: Logged In: YES user_id=89016 Checked in a fix as: Lib/test/test_codeccallbacks.py 1.15 Objects/unicodeobject.c 2.201 ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2003-10-23 13:39 Message: Logged In: YES user_id=89016 That looks like a bug with the exponential reallocation in unicodeobject.c/charmaptranslate_makespace(). I'm on it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=828737&group_id=5470 From noreply at sourceforge.net Fri Oct 24 12:26:12 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 24 12:26:25 2003 Subject: [Python-bugs-list] [ python-Bugs-822668 ] tarfile exception on large .tar files Message-ID: Bugs item #822668, was opened at 2003-10-13 07:20 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=822668&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Johan Fredrik ?hman (johanfo) >Assigned to: A.M. Kuchling (akuchling) Summary: tarfile exception on large .tar files Initial Comment: The following exception is thrown when I write a lot of data > 10Gb directly to my tapestreamer. Is this normal? Traceback (most recent call last): File "/usr/local/metroField/fieldPlugins/Backup.py", line 184, in run self._doBackup() File "/usr/local/metroField/fieldPlugins/Backup.py", line 333, in _doBackup arc.close() File "/usr/local/metroField/fieldPlugins/Backup.py", line 533, in close self.tf.close() File "/usr/local/lib/python2.3/tarfile.py", line 1009, in close self.fileobj.close() File "/usr/local/lib/python2.3/tarfile.py", line 360, in close self.fileobj.write(struct.pack(" sys. maxint*2+2, that is for files larger than 4Gb. This is not good since the newest tar and gzip versions can handle files larger than that. According to the gzip file format spec from www.wotsit.org, the last 4 bytes of a gzip file "contains the size of the original (uncompressed) input data modulo 2^32". All that has to be done is to perform this calculation prior to the call to struct. pack. Here is my proposed fix: 358: if self.type == "gz": 359: self.fileobj.write(struct.pack(" Bugs item #822668, was opened at 2003-10-13 07:20 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=822668&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Johan Fredrik ?hman (johanfo) Assigned to: A.M. Kuchling (akuchling) Summary: tarfile exception on large .tar files Initial Comment: The following exception is thrown when I write a lot of data > 10Gb directly to my tapestreamer. Is this normal? Traceback (most recent call last): File "/usr/local/metroField/fieldPlugins/Backup.py", line 184, in run self._doBackup() File "/usr/local/metroField/fieldPlugins/Backup.py", line 333, in _doBackup arc.close() File "/usr/local/metroField/fieldPlugins/Backup.py", line 533, in close self.tf.close() File "/usr/local/lib/python2.3/tarfile.py", line 1009, in close self.fileobj.close() File "/usr/local/lib/python2.3/tarfile.py", line 360, in close self.fileobj.write(struct.pack("Comment By: A.M. Kuchling (akuchling) Date: 2003-10-24 13:39 Message: Logged In: YES user_id=11375 Thanks for reporting this bug; your suggested change seems to be correct. Applied to CVS as rev. 1.9 of tarfile.py The Jython bug should be reported to whatever bug tracker the Jython developers use; they won't see the bug if it's in this bug tracker. Try looking at www.jython.org. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-15 16:17 Message: Logged In: YES user_id=887415 Hi, I think I've found the correct solution to the problem (though I havn't actually tested it). Looking in tarfile.py... 358: if self.type == "gz": 359: self.fileobj.write(struct.pack(" sys. maxint*2+2, that is for files larger than 4Gb. This is not good since the newest tar and gzip versions can handle files larger than that. According to the gzip file format spec from www.wotsit.org, the last 4 bytes of a gzip file "contains the size of the original (uncompressed) input data modulo 2^32". All that has to be done is to perform this calculation prior to the call to struct. pack. Here is my proposed fix: 358: if self.type == "gz": 359: self.fileobj.write(struct.pack(" Bugs item #829532, was opened at 2003-10-24 07:44 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs() cannot handle "." Initial Comment: Invoking os.makedirs() with an argument that contains a directory name with a single dot fails. The resulting error is confusing: "File exists". The problem is that the path is split up in pieces and an attempt is made to create the "." directory. This always exists, of course. It happens anyway, because the test for existence is done before creating the directory that contains ".". There are various possible solutions: 1. First normalize the path so that "." entries are removed. This would also work for ".." entries. But it might cause trouble for symbolic links and there is a performance penalty. 2. Check for existence of the directory again after the recursive call to create the directory that contains the entry. This will cause the normal error for an existing directory to be skipped, unless an extra flag is added. This gets complicated. 3. Simply skip creating a directory with the name ".". I propose to use the third solution. I have attached a patch for this. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-10-24 13:46 Message: Logged In: YES user_id=11375 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 From noreply at sourceforge.net Fri Oct 24 15:49:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 24 15:49:35 2003 Subject: [Python-bugs-list] [ python-Feature Requests-793798 ] Redirect file output into variables Message-ID: Feature Requests item #793798, was opened at 2003-08-23 17:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793798&group_id=5470 Category: Python Library Group: None >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Markus Elfring (elfring) Assigned to: Martin v. L?wis (loewis) Summary: Redirect file output into variables Initial Comment: The PHP programming language provides output control functions (http://de.php.net/manual/en/ref.outcontrol.php, e. g. "ob_get_contents"). I am looking for similar functionality to use with phyton. 1. I suggest to add a parameter that specifies a variable name. open(file, flags[, mode[, variable name]]) fdopen(fd[, mode[, bufsize[, variable name]]]) 2. Another technique is to implement a virtual file system that converts variables into special files. Has anybody tried to create a file system interface for variables before? A code example can be found with a similar feature request for TCL. https://sourceforge.net/tracker/?func=detail&aid=792990&group_id=10894&atid=360894 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-24 21:49 Message: Logged In: YES user_id=21627 This is not a reason to reopen the feature request. Ask in comp.lang.python if you need help. ---------------------------------------------------------------------- Comment By: Markus Elfring (elfring) Date: 2003-10-24 15:51 Message: Logged In: YES user_id=572001 I can not see by the description "http://www.python.org/doc/current/lib/module- StringIO.html" how STDOUT (http://www.python.org/doc/current/lib/os-fd-ops.html) can be redirected. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-20 23:09 Message: Logged In: YES user_id=21627 This is already available. StringIO/cStringIO allow readily to output streams into memory. Use it like this variable = cStringIO.StringIO() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=793798&group_id=5470 From noreply at sourceforge.net Fri Oct 24 15:59:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 24 16:00:01 2003 Subject: [Python-bugs-list] [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 05:21 Message generated for change (Comment added) made by billbaxter26 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: Later Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) 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: Bill Baxter (billbaxter26) Date: 2003-10-24 15: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 #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 #include --------------------------------------------------------------------------- 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 06: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 22: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 14: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 07: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 #include #include #include 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 08: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 03: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 14: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 09: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 09: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 20: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 18:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" To: "Ralf W. Grosse-Kunstleve" 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 #include . . . 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 10: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 02: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 19: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 13: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 14: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 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 08: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 Oct 24 16:13:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 24 16:14:16 2003 Subject: [Python-bugs-list] [ python-Bugs-829458 ] setattr(obj, BADNAME, value) does not raises exception Message-ID: Bugs item #829458, was opened at 2003-10-24 09:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: setattr(obj, BADNAME, value) does not raises exception Initial Comment: Now I just realize that setattr() does not check value of the name argument but simply insert the named value in __dict__ so setattr(obj, BADNAME, value) not equal to obj.BADNAME = value. It's true for new and old style classes and all python versions which I have tried (1.5, 2.1, 2.2, 2.3). Should not setattr(obj, BADNAME, value) raise appropriate exception (AttributeError or maybe ValueError)? For example: >>> class Test: pass ... >>> o = Test() >>> setattr(o, "test.test", 100) >>> setattr(o, "12345", 200) >>> dir(o) ['12345', '__doc__', '__module__', 'test.test'] ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-24 22:13 Message: Logged In: YES user_id=21627 I don't see it as a big problem, but I would not object much to a change. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 From noreply at sourceforge.net Fri Oct 24 16:15:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 24 16:16:56 2003 Subject: [Python-bugs-list] [ python-Bugs-823672 ] os.strerror doesn't understand windows error codes Message-ID: Bugs item #823672, was opened at 2003-10-14 22:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823672&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: os.strerror doesn't understand windows error codes Initial Comment: For example, os.strerror(errno.EWOULDBLOCK) returns 'unknown error'. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-24 22:15 Message: Logged In: YES user_id=21627 Why is this a bug in Python? os.strerror just calls the system's strerror(3). If that doesn't know its own errors, how should Python know? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823672&group_id=5470 From noreply at sourceforge.net Fri Oct 24 18:30:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 24 18:31:10 2003 Subject: [Python-bugs-list] [ python-Bugs-827760 ] Bug in dbm - long strings in keys and values Message-ID: Bugs item #827760, was opened at 2003-10-21 13:05 Message generated for change (Settings changed) made by jdcrunchman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827760&group_id=5470 >Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: John Draper (jdcrunchman) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in dbm - long strings in keys and values Initial Comment: #!/usr/local/bin/python #2003-10-19. Feedback to crunch@shopip.com import dbm print """ Python dbm bugs summary: 1. Long strings cause weirdness. 2. Long keys fail without returning error. This demonstrates serious bugs in the Python dbm module. Present in OpenBSD versions 2.2, 2.3, and 2.3.2c1. len(key+string)>61231 results in the item being 'lost', without warning. If the key or string is one character shorter, it is fine. Writing multiple long strings causes unpredictable results (none, some, or all of the items are lost without warning). Curiously, keys of length 57148 return an error, but longer keys fail without warning (sounds like an = instead of a > somewhere). """ mdb=dbm.open("mdb","n") print "Writing 1 item to database, but upon reading," k='k' v='X'*61230 #Long string mdb[k]=v mdb.close() md=dbm.open("mdb","r") print "database contains %i items"%len(md.keys()) md.close() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827760&group_id=5470 From noreply at sourceforge.net Fri Oct 24 18:47:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 24 18:47:24 2003 Subject: [Python-bugs-list] [ python-Bugs-827760 ] Bug in dbm - long strings in keys and values Message-ID: Bugs item #827760, was opened at 2003-10-21 13:05 Message generated for change (Comment added) made by jdcrunchman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827760&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: John Draper (jdcrunchman) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in dbm - long strings in keys and values Initial Comment: #!/usr/local/bin/python #2003-10-19. Feedback to crunch@shopip.com import dbm print """ Python dbm bugs summary: 1. Long strings cause weirdness. 2. Long keys fail without returning error. This demonstrates serious bugs in the Python dbm module. Present in OpenBSD versions 2.2, 2.3, and 2.3.2c1. len(key+string)>61231 results in the item being 'lost', without warning. If the key or string is one character shorter, it is fine. Writing multiple long strings causes unpredictable results (none, some, or all of the items are lost without warning). Curiously, keys of length 57148 return an error, but longer keys fail without warning (sounds like an = instead of a > somewhere). """ mdb=dbm.open("mdb","n") print "Writing 1 item to database, but upon reading," k='k' v='X'*61230 #Long string mdb[k]=v mdb.close() md=dbm.open("mdb","r") print "database contains %i items"%len(md.keys()) md.close() ---------------------------------------------------------------------- >Comment By: John Draper (jdcrunchman) Date: 2003-10-24 15:47 Message: Logged In: YES user_id=891874 I upped the priority since this bug causes dbm database corruption, which could be disastrous for users of dbm or shelve. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827760&group_id=5470 From noreply at sourceforge.net Fri Oct 24 22:12:06 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 24 22:12:16 2003 Subject: [Python-bugs-list] [ python-Bugs-829941 ] Now built-in types can be used as base classes. Fix the tut. Message-ID: Bugs item #829941, was opened at 2003-10-25 11:12 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=829941&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Seo Sanghyeon (sanxiyn) Assigned to: Nobody/Anonymous (nobody) Summary: Now built-in types can be used as base classes. Fix the tut. Initial Comment: Current Python Tutorial asserts in Chapter 9, "Classes": But, just like in C++ or Modula-3, built-in types cannot be used as base classes for extension by the user. This is no longer true. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829941&group_id=5470 From noreply at sourceforge.net Sat Oct 25 05:29:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 25 05:29:46 2003 Subject: [Python-bugs-list] [ python-Bugs-827856 ] object.h misdocuments PyDict_SetItemString Message-ID: Bugs item #827856, was opened at 2003-10-22 00:47 Message generated for change (Comment added) made by johahn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827856&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: object.h misdocuments PyDict_SetItemString Initial Comment: I just happened to notice the following in the comment titled "Reference Counts" toward the end of object.h (2.3.2): Functions that 'store' objects such as PyTuple_SetItem () and PyDict_SetItemString() don't increment the reference count of the object I believe PyDict_SetItemString does increment the refcount. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-25 11:29 Message: Logged In: YES user_id=887415 Hi Greg, you are right, whoever wrote it probably meant PyList_SetItem (according to Ref.Manual 1.2.1.1 and source). Will you submit a patch? ...johahn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827856&group_id=5470 From noreply at sourceforge.net Sat Oct 25 06:46:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 25 06:46:27 2003 Subject: [Python-bugs-list] [ python-Bugs-827190 ] wrong error message of islice indexing Message-ID: Bugs item #827190, was opened at 2003-10-21 00:46 Message generated for change (Comment added) made by johahn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827190&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: wrong error message of islice indexing Initial Comment: If you pass negative values to itertools.islice, you get a wrong error message. Indices for itertools.islice() may be non-negative integers(zero is included), but the error message says that they must be positive. I think the message needs to be corrected. >>> from itertools import islice >>> l = range(5) >>> islice(l, 0, None) >>> islice(l, -1, None) Traceback (most recent call last): File "", line 1, in ? ValueError: Indices for islice() must be positive. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-25 12:46 Message: Logged In: YES user_id=887415 Patch submitted. Error message changed to "Indices for islice() must be non-negative." Also fixed >>> islice('abc', -1). http://sourceforge.net/tracker/index.php? func=detail&aid=830070&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827190&group_id=5470 From noreply at sourceforge.net Sat Oct 25 07:54:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 25 07:54:37 2003 Subject: [Python-bugs-list] [ python-Bugs-829458 ] setattr(obj, BADNAME, value) does not raises exception Message-ID: Bugs item #829458, was opened at 2003-10-24 11:53 Message generated for change (Comment added) made by hdima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: setattr(obj, BADNAME, value) does not raises exception Initial Comment: Now I just realize that setattr() does not check value of the name argument but simply insert the named value in __dict__ so setattr(obj, BADNAME, value) not equal to obj.BADNAME = value. It's true for new and old style classes and all python versions which I have tried (1.5, 2.1, 2.2, 2.3). Should not setattr(obj, BADNAME, value) raise appropriate exception (AttributeError or maybe ValueError)? For example: >>> class Test: pass ... >>> o = Test() >>> setattr(o, "test.test", 100) >>> setattr(o, "12345", 200) >>> dir(o) ['12345', '__doc__', '__module__', 'test.test'] ---------------------------------------------------------------------- >Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-25 15:54 Message: Logged In: YES user_id=388573 Ok. I'll start working on it on the next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-25 00:13 Message: Logged In: YES user_id=21627 I don't see it as a big problem, but I would not object much to a change. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 From noreply at sourceforge.net Sat Oct 25 09:50:41 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 25 09:51:06 2003 Subject: [Python-bugs-list] [ python-Bugs-829458 ] setattr(obj, BADNAME, value) does not raises exception Message-ID: Bugs item #829458, was opened at 2003-10-24 09:53 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: setattr(obj, BADNAME, value) does not raises exception Initial Comment: Now I just realize that setattr() does not check value of the name argument but simply insert the named value in __dict__ so setattr(obj, BADNAME, value) not equal to obj.BADNAME = value. It's true for new and old style classes and all python versions which I have tried (1.5, 2.1, 2.2, 2.3). Should not setattr(obj, BADNAME, value) raise appropriate exception (AttributeError or maybe ValueError)? For example: >>> class Test: pass ... >>> o = Test() >>> setattr(o, "test.test", 100) >>> setattr(o, "12345", 200) >>> dir(o) ['12345', '__doc__', '__module__', 'test.test'] ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-10-25 15:50 Message: Logged In: YES user_id=11105 Hm, you mean setattr() should only accept strings containing valid Python identifiers as the second argument, and choke on something like "123" or "a.b.c.d"? I would strongly object to this change, in fact I'm using it quite often. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-25 13:54 Message: Logged In: YES user_id=388573 Ok. I'll start working on it on the next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-24 22:13 Message: Logged In: YES user_id=21627 I don't see it as a big problem, but I would not object much to a change. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 From noreply at sourceforge.net Sat Oct 25 10:17:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 25 10:17:49 2003 Subject: [Python-bugs-list] [ python-Bugs-829941 ] Now built-in types can be used as base classes. Fix the tut. Message-ID: Bugs item #829941, was opened at 2003-10-24 22:12 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829941&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Seo Sanghyeon (sanxiyn) >Assigned to: Neal Norwitz (nnorwitz) Summary: Now built-in types can be used as base classes. Fix the tut. Initial Comment: Current Python Tutorial asserts in Chapter 9, "Classes": But, just like in C++ or Modula-3, built-in types cannot be used as base classes for extension by the user. This is no longer true. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-25 10:17 Message: Logged In: YES user_id=33168 Thanks! Checked in as: Doc/tut/tut.tex 1.209 and 1.196.8.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829941&group_id=5470 From noreply at sourceforge.net Sat Oct 25 17:57:11 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 25 17:57:22 2003 Subject: [Python-bugs-list] [ python-Bugs-830261 ] __mul__ taken as __rmul__ for mul-by-int only Message-ID: Bugs item #830261, was opened at 2003-10-25 23:57 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=830261&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: __mul__ taken as __rmul__ for mul-by-int only Initial Comment: Tiniest way to reproduce: >>> class X(object): ... def __mul__(self, other): return '%r???' % other ... >>> x=X() >>> 23*x '23???' >>> 2.3*x Traceback (most recent call last): File "", line 1, in ? TypeError: can't multiply sequence to non-int >>> weird error message hints at cause: Objects/typeobject.c sets sq_repeat slot indifferently for both __mul__ AND __rmul__, then Objects/abstract.c function PyNumber_Multiply checks both operands for sq_repeats, finds it in the RHO and thus calls sequence_repeat which erroneously succeeds when the LHO is 23 and fails w/weird error message when it's 2.3. I'm leaving this unassigned because it's anything but obvious to me what the fix should be! If anybody HAS obvious fixes to suggest I'll be glad to implement and commit them, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830261&group_id=5470 From noreply at sourceforge.net Sat Oct 25 23:57:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sat Oct 25 23:57:55 2003 Subject: [Python-bugs-list] [ python-Bugs-830347 ] python-mode.el: py-b-of-def-or-class looks inside strings Message-ID: Bugs item #830347, was opened at 2003-10-26 03:57 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=830347&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dale Hagglund (dhagglund) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el: py-b-of-def-or-class looks inside strings Initial Comment: Using python-mode.el 4.6 and gnu emacs 21.1. To demonstrate this problem: 1. Open the attached file with emacs. 2. Position point at the "#" on the last line. 3. Type `M-C-a', py-beginning-of-def-or-class. Point will now be inside the docstring for class x. py-b-o-d-o-c uses regexps to look backwards for def or class lines. When it finds a candidate line, should it maybe use partial-parse-sexp to decide if it's in a string or not? I apologize if this issue has been raised before, but I wasn't able to figure out how to do keyword searches with sourceforge. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830347&group_id=5470 From noreply at sourceforge.net Sun Oct 26 01:32:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 26 01:32:22 2003 Subject: [Python-bugs-list] [ python-Bugs-830347 ] python-mode.el: py-b-of-def-or-class looks inside strings Message-ID: Bugs item #830347, was opened at 2003-10-26 03:57 Message generated for change (Comment added) made by dhagglund You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830347&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dale Hagglund (dhagglund) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el: py-b-of-def-or-class looks inside strings Initial Comment: Using python-mode.el 4.6 and gnu emacs 21.1. To demonstrate this problem: 1. Open the attached file with emacs. 2. Position point at the "#" on the last line. 3. Type `M-C-a', py-beginning-of-def-or-class. Point will now be inside the docstring for class x. py-b-o-d-o-c uses regexps to look backwards for def or class lines. When it finds a candidate line, should it maybe use partial-parse-sexp to decide if it's in a string or not? I apologize if this issue has been raised before, but I wasn't able to figure out how to do keyword searches with sourceforge. ---------------------------------------------------------------------- >Comment By: Dale Hagglund (dhagglund) Date: 2003-10-26 05:32 Message: Logged In: YES user_id=895011 I guess I should have waited a bit longer before filing this as a bug. The attached patch resolves this bug for me. This patch also fixes a minor related bug in py-end-of-def-or-class. If COUNT was greater than zero, the call to py-beginning-of-def-or-class was incorrect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830347&group_id=5470 From noreply at sourceforge.net Sun Oct 26 04:09:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 26 04:09:37 2003 Subject: [Python-bugs-list] [ python-Bugs-829458 ] setattr(obj, BADNAME, value) does not raises exception Message-ID: Bugs item #829458, was opened at 2003-10-24 11:53 Message generated for change (Comment added) made by hdima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: setattr(obj, BADNAME, value) does not raises exception Initial Comment: Now I just realize that setattr() does not check value of the name argument but simply insert the named value in __dict__ so setattr(obj, BADNAME, value) not equal to obj.BADNAME = value. It's true for new and old style classes and all python versions which I have tried (1.5, 2.1, 2.2, 2.3). Should not setattr(obj, BADNAME, value) raise appropriate exception (AttributeError or maybe ValueError)? For example: >>> class Test: pass ... >>> o = Test() >>> setattr(o, "test.test", 100) >>> setattr(o, "12345", 200) >>> dir(o) ['12345', '__doc__', '__module__', 'test.test'] ---------------------------------------------------------------------- >Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-26 12:09 Message: Logged In: YES user_id=388573 Give me some use case examples. Maybe you use object's __dict__ like general purpose dictionary? If so, it seems ugly for me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-25 17:50 Message: Logged In: YES user_id=11105 Hm, you mean setattr() should only accept strings containing valid Python identifiers as the second argument, and choke on something like "123" or "a.b.c.d"? I would strongly object to this change, in fact I'm using it quite often. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-25 15:54 Message: Logged In: YES user_id=388573 Ok. I'll start working on it on the next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-25 00:13 Message: Logged In: YES user_id=21627 I don't see it as a big problem, but I would not object much to a change. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 From noreply at sourceforge.net Sun Oct 26 07:20:32 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 26 07:20:44 2003 Subject: [Python-bugs-list] [ python-Bugs-830449 ] Config parser don't raise DuplicateSectionError when reading Message-ID: Bugs item #830449, was opened at 2003-10-26 14:20 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=830449&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Config parser don't raise DuplicateSectionError when reading Initial Comment: According to the documentation of ConfigParser "DuplicateSectionError" it is raised if multiple sections with the same name are found. In the code this is not the case (it continues to update the section with the same name (see ConfigParser.py line 447). Either fix the code (which I prefer :-) of the documentation. Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830449&group_id=5470 From noreply at sourceforge.net Sun Oct 26 10:06:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 26 10:07:13 2003 Subject: [Python-bugs-list] [ python-Bugs-827760 ] Bug in dbm - long strings in keys and values Message-ID: Bugs item #827760, was opened at 2003-10-21 22:05 Message generated for change (Comment added) made by tinolange You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827760&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: John Draper (jdcrunchman) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in dbm - long strings in keys and values Initial Comment: #!/usr/local/bin/python #2003-10-19. Feedback to crunch@shopip.com import dbm print """ Python dbm bugs summary: 1. Long strings cause weirdness. 2. Long keys fail without returning error. This demonstrates serious bugs in the Python dbm module. Present in OpenBSD versions 2.2, 2.3, and 2.3.2c1. len(key+string)>61231 results in the item being 'lost', without warning. If the key or string is one character shorter, it is fine. Writing multiple long strings causes unpredictable results (none, some, or all of the items are lost without warning). Curiously, keys of length 57148 return an error, but longer keys fail without warning (sounds like an = instead of a > somewhere). """ mdb=dbm.open("mdb","n") print "Writing 1 item to database, but upon reading," k='k' v='X'*61230 #Long string mdb[k]=v mdb.close() md=dbm.open("mdb","r") print "database contains %i items"%len(md.keys()) md.close() ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2003-10-26 16:06 Message: Logged In: YES user_id=212920 Hi! This is no bug - at least no python bug. It seems to be a limitation in the underlying dbm engine. I tested it with different dbm implementations under Linux today. You are right - when using dbm as ndbm.h (which belongs to libc6, i.e. db1/ndbm.h) this error/limitation occurs. Please test: At least for me the dbm engine still finds the data if you specify it, a print md[k] shows the long v string. Only the keys() and len() methods which iterate over the database fail. I also tested without Python, i. e. just using the C-API and it's just the same (linking against libdb1.so). It is the underlying dbm_firstkey() which fails when using that HUGE keys. It just returns NULL. Context: -------- drec=dbm_firstkey(dbm); while(drec.dptr) { size++; drec = dbm_nextkey(dbm); } If you happen to have a system that uses gdbm/ndbm.h as dbm.h (for example SuSE) or if you change the links in your include and lib directories accordingly and recompile Python then this bug disappears and your program is working as expected. The GNU gdbm engine (I tested 1.73 and 1.8.3) seems to be much better in handling huge keys as the old libc dbm. If possible change to gdbm or assure that dbm is linked against gdbm (-compat). setup.py tries to be smart about that but sometimes chooses the old dbm even if it could use gdbm instead. ldd /usr/local/lib/python2.3/lib-dynload/dbm.so shows you what lib you're using. On my Debian system an ln -sf /usr/include/gdbm/ndbm.h /usr/include/ndbm.h ln -sf /usr/lib/libgdbm.so /usr/lib/libndbm.so fixed it. Ciao Tino ---------------------------------------------------------------------- Comment By: John Draper (jdcrunchman) Date: 2003-10-25 00:47 Message: Logged In: YES user_id=891874 I upped the priority since this bug causes dbm database corruption, which could be disastrous for users of dbm or shelve. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827760&group_id=5470 From noreply at sourceforge.net Sun Oct 26 12:16:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 26 12:17:05 2003 Subject: [Python-bugs-list] [ python-Bugs-830573 ] python 2.3.2 make test segfault Message-ID: Bugs item #830573, was opened at 2003-10-26 18: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=830573&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Karel Kulhav? (clock_) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.3.2 make test segfault Initial Comment: When compiling python 2.3.2 on my platform, running make test produces segfault of python executable. typescript included. gcc 3.2.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830573&group_id=5470 From noreply at sourceforge.net Sun Oct 26 16:18:37 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Sun Oct 26 16:18:53 2003 Subject: [Python-bugs-list] [ python-Bugs-830449 ] Config parser don't raise DuplicateSectionError when reading Message-ID: Bugs item #830449, was opened at 2003-10-26 13:20 Message generated for change (Comment added) made by johahn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830449&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: Config parser don't raise DuplicateSectionError when reading Initial Comment: According to the documentation of ConfigParser "DuplicateSectionError" it is raised if multiple sections with the same name are found. In the code this is not the case (it continues to update the section with the same name (see ConfigParser.py line 447). Either fix the code (which I prefer :-) of the documentation. Miki ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-26 22:18 Message: Logged In: YES user_id=887415 I hereby confirm the bug and I've included some sample code of it as well. Though I don't know which solution is the best. Fixing the code might break some production code that uses duplicate sections and it is therefor easier to just change the documentation. I also don't see reason to why they should be disallowed in the first place. >>> import ConfigParser >>> cp = ConfigParser.ConfigParser() >>> from StringIO import StringIO >>> fp = StringIO(""" ; [section1] var1=option1 [section2] var2=option2 [section1] var3=option3 """) >>> cp.readfp(fp) >>> [x for x in cp.items('sec1')] [('var1', 'option1'), ('var3', 'option3')] >>> ...johahn ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830449&group_id=5470 From noreply at sourceforge.net Mon Oct 27 09:06:36 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 09:06:55 2003 Subject: [Python-bugs-list] [ python-Bugs-830573 ] python 2.3.2 make test segfault Message-ID: Bugs item #830573, was opened at 2003-10-26 12:16 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830573&group_id=5470 >Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Karel Kulhav? (clock_) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.3.2 make test segfault Initial Comment: When compiling python 2.3.2 on my platform, running make test produces segfault of python executable. typescript included. gcc 3.2.2 ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-27 09:06 Message: Logged In: YES user_id=33168 The test that crashes is anydbm. I wonder if this could be related to the bsddb problems? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830573&group_id=5470 From noreply at sourceforge.net Mon Oct 27 09:08:56 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 09:09:18 2003 Subject: [Python-bugs-list] [ python-Bugs-830347 ] python-mode.el: py-b-of-def-or-class looks inside strings Message-ID: Bugs item #830347, was opened at 2003-10-25 23:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830347&group_id=5470 Category: Demos and Tools Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dale Hagglund (dhagglund) Assigned to: Nobody/Anonymous (nobody) Summary: python-mode.el: py-b-of-def-or-class looks inside strings Initial Comment: Using python-mode.el 4.6 and gnu emacs 21.1. To demonstrate this problem: 1. Open the attached file with emacs. 2. Position point at the "#" on the last line. 3. Type `M-C-a', py-beginning-of-def-or-class. Point will now be inside the docstring for class x. py-b-o-d-o-c uses regexps to look backwards for def or class lines. When it finds a candidate line, should it maybe use partial-parse-sexp to decide if it's in a string or not? I apologize if this issue has been raised before, but I wasn't able to figure out how to do keyword searches with sourceforge. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-27 09:08 Message: Logged In: YES user_id=33168 This bug/patch should be submitted to the python-mode project. Thanks for the patch! ---------------------------------------------------------------------- Comment By: Dale Hagglund (dhagglund) Date: 2003-10-26 01:32 Message: Logged In: YES user_id=895011 I guess I should have waited a bit longer before filing this as a bug. The attached patch resolves this bug for me. This patch also fixes a minor related bug in py-end-of-def-or-class. If COUNT was greater than zero, the call to py-beginning-of-def-or-class was incorrect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830347&group_id=5470 From noreply at sourceforge.net Mon Oct 27 09:09:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 09:09:40 2003 Subject: [Python-bugs-list] [ python-Bugs-792101 ] urllib.urlopen for https doesn't always provide readlines Message-ID: Bugs item #792101, was opened at 2003-08-20 20:50 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792101&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gary Feldman (garyfx) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen for https doesn't always provide readlines Initial Comment: The doc for urllib.urlopen says that the object returned supports readlines. However, I have a simple case where it doesn't seem to raise IOError, but readlines isn't provided. The initial problem seems to be in addbase.__init__, which tests fp for readlines, but doesn't do anything if it's not there. Presumably it should either provide a dummy or raise an error (or alternatively, change the documented behavior to match). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-27 15:09 Message: Logged In: YES user_id=21627 Fixed with said patch. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-04 22:29 Message: Logged In: YES user_id=139865 SSLFile was providing a minimal set of file operations. Patch #817854 adds all methods that the urllib documentation expects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792101&group_id=5470 From noreply at sourceforge.net Mon Oct 27 09:11:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 09:12:01 2003 Subject: [Python-bugs-list] [ python-Bugs-830573 ] python 2.3.2 make test segfault Message-ID: Bugs item #830573, was opened at 2003-10-26 18:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830573&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Karel Kulhav? (clock_) Assigned to: Nobody/Anonymous (nobody) Summary: python 2.3.2 make test segfault Initial Comment: When compiling python 2.3.2 on my platform, running make test produces segfault of python executable. typescript included. gcc 3.2.2 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-27 15:11 Message: Logged In: YES user_id=21627 Can you provide more detail about your platform (e.g. OS name, OS vendor, version of BerkeleyDB installed). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-27 15:06 Message: Logged In: YES user_id=33168 The test that crashes is anydbm. I wonder if this could be related to the bsddb problems? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=830573&group_id=5470 From noreply at sourceforge.net Mon Oct 27 09:44:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 09:45:04 2003 Subject: [Python-bugs-list] [ python-Bugs-792101 ] urllib.urlopen for https doesn't always provide readlines Message-ID: Bugs item #792101, was opened at 2003-08-20 14:50 Message generated for change (Comment added) made by garyfx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792101&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Gary Feldman (garyfx) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen for https doesn't always provide readlines Initial Comment: The doc for urllib.urlopen says that the object returned supports readlines. However, I have a simple case where it doesn't seem to raise IOError, but readlines isn't provided. The initial problem seems to be in addbase.__init__, which tests fp for readlines, but doesn't do anything if it's not there. Presumably it should either provide a dummy or raise an error (or alternatively, change the documented behavior to match). ---------------------------------------------------------------------- >Comment By: Gary Feldman (garyfx) Date: 2003-10-27 09:44 Message: Logged In: YES user_id=847172 I'm not sure what the protocol is for responding to bug fixes, but I do want to thank the folks responsible for getting this fixed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-27 09:09 Message: Logged In: YES user_id=21627 Fixed with said patch. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-04 16:29 Message: Logged In: YES user_id=139865 SSLFile was providing a minimal set of file operations. Patch #817854 adds all methods that the urllib documentation expects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792101&group_id=5470 From noreply at sourceforge.net Mon Oct 27 09:55:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 09:56:35 2003 Subject: [Python-bugs-list] [ python-Bugs-792101 ] urllib.urlopen for https doesn't always provide readlines Message-ID: Bugs item #792101, was opened at 2003-08-20 14:50 Message generated for change (Comment added) made by garyfx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792101&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Gary Feldman (garyfx) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlopen for https doesn't always provide readlines Initial Comment: The doc for urllib.urlopen says that the object returned supports readlines. However, I have a simple case where it doesn't seem to raise IOError, but readlines isn't provided. The initial problem seems to be in addbase.__init__, which tests fp for readlines, but doesn't do anything if it's not there. Presumably it should either provide a dummy or raise an error (or alternatively, change the documented behavior to match). ---------------------------------------------------------------------- >Comment By: Gary Feldman (garyfx) Date: 2003-10-27 09:55 Message: Logged In: YES user_id=847172 I'm not sure what the protocol is for responding to bug fixes, but I do want to thank the folks responsible for getting this fixed. ---------------------------------------------------------------------- Comment By: Gary Feldman (garyfx) Date: 2003-10-27 09:44 Message: Logged In: YES user_id=847172 I'm not sure what the protocol is for responding to bug fixes, but I do want to thank the folks responsible for getting this fixed. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-27 09:09 Message: Logged In: YES user_id=21627 Fixed with said patch. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-04 16:29 Message: Logged In: YES user_id=139865 SSLFile was providing a minimal set of file operations. Patch #817854 adds all methods that the urllib documentation expects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792101&group_id=5470 From noreply at sourceforge.net Mon Oct 27 14:44:08 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 14:44:29 2003 Subject: [Python-bugs-list] [ python-Bugs-823209 ] cmath.log doesn't have the same interface as math.log. Message-ID: Bugs item #823209, was opened at 2003-10-13 23:23 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823209&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: cmath.log doesn't have the same interface as math.log. Initial Comment: Somewhere along the way, math.log gained an optional "base" argument. cmath.log is still missing it. >>> print math.log.__doc__ log(x[, base]) -> the logarithm of x to the given base. If the base not specified, returns the natural logarithm (base e) of x. >>> print cmath.log.__doc__ log(x) Return the natural logarithm of x. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-27 14:44 Message: Logged In: YES user_id=80475 I can fix this if necessary. My question is whether it should be done. On the one hand, it is nice to have the two interfaces as symmetrical as possible. OTOH, I'm not aware of any use cases for log(z, b). ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-18 13:42 Message: Logged In: YES user_id=139865 See patch #826074 for a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823209&group_id=5470 From noreply at sourceforge.net Mon Oct 27 14:57:35 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 14:57:50 2003 Subject: [Python-bugs-list] [ python-Bugs-831271 ] httplib.HTTPConnection._send_request header parsing bug Message-ID: Bugs item #831271, was opened at 2003-10-27 12:57 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=831271&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Coombs (jaraco) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831271&group_id=5470 From noreply at sourceforge.net Mon Oct 27 15:05:30 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 15:05:42 2003 Subject: [Python-bugs-list] [ python-Bugs-827902 ] ctime is not creation time Message-ID: Bugs item #827902, was opened at 2003-10-21 19:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: ctime is not creation time Initial Comment: Hi! http://python.org/doc/current/lib/module-os.path.html says getctime() returns the creation time. But it probably returns the ctime, which has nothing to do with creation. Bye, Robert ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-27 15:05 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libposixpath.tex 1.37 and 1.36.12.1. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-23 03:14 Message: Logged In: YES user_id=887415 On Windows 2000 os.path.ctime (-> ntpath.getctime -> ntpath.stat.st_ctime) returns creation time. ---------------------------------------------------------------------- Comment By: Robert Siemer (siemer) Date: 2003-10-22 17:11 Message: Logged In: YES user_id=150699 ctime is the time of last modification of file status information. Means: gets updated on everything... (-: There is no way on classic Linux-Filesystems to get the creation time. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-22 16:14 Message: Logged In: YES user_id=43607 ctime is change time. Read the manual (stat(2)): time_t st_atime; /* time of last access */ time_t st_mtime; /* time of last modification */ time_t st_ctime; /* time of last change */ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-22 11:02 Message: Logged In: YES user_id=21627 Why do you say ctime has nothing to do with creation? What else does ctime indicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 From noreply at sourceforge.net Mon Oct 27 15:17:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 15:17:37 2003 Subject: [Python-bugs-list] [ python-Bugs-827902 ] ctime is not creation time Message-ID: Bugs item #827902, was opened at 2003-10-21 19:32 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: ctime is not creation time Initial Comment: Hi! http://python.org/doc/current/lib/module-os.path.html says getctime() returns the creation time. But it probably returns the ctime, which has nothing to do with creation. Bye, Robert ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-27 15:05 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libposixpath.tex 1.37 and 1.36.12.1. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-23 03:14 Message: Logged In: YES user_id=887415 On Windows 2000 os.path.ctime (-> ntpath.getctime -> ntpath.stat.st_ctime) returns creation time. ---------------------------------------------------------------------- Comment By: Robert Siemer (siemer) Date: 2003-10-22 17:11 Message: Logged In: YES user_id=150699 ctime is the time of last modification of file status information. Means: gets updated on everything... (-: There is no way on classic Linux-Filesystems to get the creation time. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-22 16:14 Message: Logged In: YES user_id=43607 ctime is change time. Read the manual (stat(2)): time_t st_atime; /* time of last access */ time_t st_mtime; /* time of last modification */ time_t st_ctime; /* time of last change */ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-22 11:02 Message: Logged In: YES user_id=21627 Why do you say ctime has nothing to do with creation? What else does ctime indicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 From noreply at sourceforge.net Mon Oct 27 15:20:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 15:21:16 2003 Subject: [Python-bugs-list] [ python-Bugs-823209 ] cmath.log doesn't have the same interface as math.log. Message-ID: Bugs item #823209, was opened at 2003-10-13 23:23 Message generated for change (Comment added) made by gaul You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823209&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: cmath.log doesn't have the same interface as math.log. Initial Comment: Somewhere along the way, math.log gained an optional "base" argument. cmath.log is still missing it. >>> print math.log.__doc__ log(x[, base]) -> the logarithm of x to the given base. If the base not specified, returns the natural logarithm (base e) of x. >>> print cmath.log.__doc__ log(x) Return the natural logarithm of x. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-27 14:20 Message: Logged In: YES user_id=139865 Base 2 logarithms are somewhat common. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-27 13:44 Message: Logged In: YES user_id=80475 I can fix this if necessary. My question is whether it should be done. On the one hand, it is nice to have the two interfaces as symmetrical as possible. OTOH, I'm not aware of any use cases for log(z, b). ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-18 13:42 Message: Logged In: YES user_id=139865 See patch #826074 for a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823209&group_id=5470 From noreply at sourceforge.net Mon Oct 27 17:03:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 17:03:31 2003 Subject: [Python-bugs-list] [ python-Bugs-823209 ] cmath.log doesn't have the same interface as math.log. Message-ID: Bugs item #823209, was opened at 2003-10-14 00:23 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823209&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: cmath.log doesn't have the same interface as math.log. Initial Comment: Somewhere along the way, math.log gained an optional "base" argument. cmath.log is still missing it. >>> print math.log.__doc__ log(x[, base]) -> the logarithm of x to the given base. If the base not specified, returns the natural logarithm (base e) of x. >>> print cmath.log.__doc__ log(x) Return the natural logarithm of x. ---------------------------------------------------------------------- >Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-27 17:03 Message: Logged In: YES user_id=99508 In my particular usecase, I define an environment in which people can execute mathematical statements like so: _mathEnv = {'__builtins__': new.module('__builtins__'), 'i': 1j} _mathEnv.update(math.__dict__) _mathEnv.update(cmath.__dict__) As you can see, the cmath definitions shadow the math definitions, and thus I lose the useful ability to offer users a log with a base (which those that know Python expect to work). That's at least my particular use case. In this particular instance, since I don't want to allow the users to cause the application to consume arbitrary amounts of memory, I can't allow integer arithmetic (because of the crazy int/long unification that left people who wanted computationall bounded arithmetic with no choice but to implement a fixed-size integer type or use float/complex instead ;)) so I use complex objects everywhere, and math.log can't operate on complex objects (even those that have no imaginary component). ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-27 15:20 Message: Logged In: YES user_id=139865 Base 2 logarithms are somewhat common. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-27 14:44 Message: Logged In: YES user_id=80475 I can fix this if necessary. My question is whether it should be done. On the one hand, it is nice to have the two interfaces as symmetrical as possible. OTOH, I'm not aware of any use cases for log(z, b). ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-18 14:42 Message: Logged In: YES user_id=139865 See patch #826074 for a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=823209&group_id=5470 From noreply at sourceforge.net Mon Oct 27 18:57:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 18:57:42 2003 Subject: [Python-bugs-list] [ python-Bugs-827902 ] ctime is not creation time Message-ID: Bugs item #827902, was opened at 2003-10-22 02:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: ctime is not creation time Initial Comment: Hi! http://python.org/doc/current/lib/module-os.path.html says getctime() returns the creation time. But it probably returns the ctime, which has nothing to do with creation. Bye, Robert ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-28 00:57 Message: Logged In: YES user_id=21627 So what about the issue that ctime really does mean "creation time" on Windows? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-27 21:05 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libposixpath.tex 1.37 and 1.36.12.1. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-23 10:14 Message: Logged In: YES user_id=887415 On Windows 2000 os.path.ctime (-> ntpath.getctime -> ntpath.stat.st_ctime) returns creation time. ---------------------------------------------------------------------- Comment By: Robert Siemer (siemer) Date: 2003-10-23 00:11 Message: Logged In: YES user_id=150699 ctime is the time of last modification of file status information. Means: gets updated on everything... (-: There is no way on classic Linux-Filesystems to get the creation time. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-22 23:14 Message: Logged In: YES user_id=43607 ctime is change time. Read the manual (stat(2)): time_t st_atime; /* time of last access */ time_t st_mtime; /* time of last modification */ time_t st_ctime; /* time of last change */ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-22 18:02 Message: Logged In: YES user_id=21627 Why do you say ctime has nothing to do with creation? What else does ctime indicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 From noreply at sourceforge.net Mon Oct 27 19:54:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 19:54:57 2003 Subject: [Python-bugs-list] [ python-Bugs-829532 ] os.makedirs() cannot handle "." Message-ID: Bugs item #829532, was opened at 2003-10-24 14:44 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: Nobody/Anonymous (nobody) Summary: os.makedirs() cannot handle "." Initial Comment: Invoking os.makedirs() with an argument that contains a directory name with a single dot fails. The resulting error is confusing: "File exists". The problem is that the path is split up in pieces and an attempt is made to create the "." directory. This always exists, of course. It happens anyway, because the test for existence is done before creating the directory that contains ".". There are various possible solutions: 1. First normalize the path so that "." entries are removed. This would also work for ".." entries. But it might cause trouble for symbolic links and there is a performance penalty. 2. Check for existence of the directory again after the recursive call to create the directory that contains the entry. This will cause the normal error for an existing directory to be skipped, unless an extra flag is added. This gets complicated. 3. Simply skip creating a directory with the name ".". I propose to use the third solution. I have attached a patch for this. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-10-28 02:54 Message: Logged In: YES user_id=539787 Minor correction (in ex cmdline style :): :%s/"\."/curdir/g in the 'diff' patch (making it more OS independent). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-10-24 20:46 Message: Logged In: YES user_id=11375 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 From noreply at sourceforge.net Mon Oct 27 20:00:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 20:00:28 2003 Subject: [Python-bugs-list] [ python-Bugs-829458 ] setattr(obj, BADNAME, value) does not raises exception Message-ID: Bugs item #829458, was opened at 2003-10-24 10:53 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: setattr(obj, BADNAME, value) does not raises exception Initial Comment: Now I just realize that setattr() does not check value of the name argument but simply insert the named value in __dict__ so setattr(obj, BADNAME, value) not equal to obj.BADNAME = value. It's true for new and old style classes and all python versions which I have tried (1.5, 2.1, 2.2, 2.3). Should not setattr(obj, BADNAME, value) raise appropriate exception (AttributeError or maybe ValueError)? For example: >>> class Test: pass ... >>> o = Test() >>> setattr(o, "test.test", 100) >>> setattr(o, "12345", 200) >>> dir(o) ['12345', '__doc__', '__module__', 'test.test'] ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-10-28 03:00 Message: Logged In: YES user_id=539787 Note: there is a valid_identifier function in Objects/typeobject.c which is being used by the __slots__ mechanism and I believe is quite handy; however, it is declared as static. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-26 11:09 Message: Logged In: YES user_id=388573 Give me some use case examples. Maybe you use object's __dict__ like general purpose dictionary? If so, it seems ugly for me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-25 16:50 Message: Logged In: YES user_id=11105 Hm, you mean setattr() should only accept strings containing valid Python identifiers as the second argument, and choke on something like "123" or "a.b.c.d"? I would strongly object to this change, in fact I'm using it quite often. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-25 14:54 Message: Logged In: YES user_id=388573 Ok. I'll start working on it on the next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-24 23:13 Message: Logged In: YES user_id=21627 I don't see it as a big problem, but I would not object much to a change. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 From noreply at sourceforge.net Mon Oct 27 21:29:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Mon Oct 27 21:29:52 2003 Subject: [Python-bugs-list] [ python-Bugs-829458 ] setattr(obj, BADNAME, value) does not raises exception Message-ID: Bugs item #829458, was opened at 2003-10-24 00:53 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: setattr(obj, BADNAME, value) does not raises exception Initial Comment: Now I just realize that setattr() does not check value of the name argument but simply insert the named value in __dict__ so setattr(obj, BADNAME, value) not equal to obj.BADNAME = value. It's true for new and old style classes and all python versions which I have tried (1.5, 2.1, 2.2, 2.3). Should not setattr(obj, BADNAME, value) raise appropriate exception (AttributeError or maybe ValueError)? For example: >>> class Test: pass ... >>> o = Test() >>> setattr(o, "test.test", 100) >>> setattr(o, "12345", 200) >>> dir(o) ['12345', '__doc__', '__module__', 'test.test'] ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-10-27 18:29 Message: Logged In: YES user_id=357491 I am going to argue for "no" on this one. The major point of setattr is that it allows you to set an attribute for *any* name after compile time. This should go for even attribute names that would not normally work. It is a rather powerful ability that I think should stay. Anyone else care to weigh in on this? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-10-27 17:00 Message: Logged In: YES user_id=539787 Note: there is a valid_identifier function in Objects/typeobject.c which is being used by the __slots__ mechanism and I believe is quite handy; however, it is declared as static. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-26 01:09 Message: Logged In: YES user_id=388573 Give me some use case examples. Maybe you use object's __dict__ like general purpose dictionary? If so, it seems ugly for me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-25 06:50 Message: Logged In: YES user_id=11105 Hm, you mean setattr() should only accept strings containing valid Python identifiers as the second argument, and choke on something like "123" or "a.b.c.d"? I would strongly object to this change, in fact I'm using it quite often. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-25 04:54 Message: Logged In: YES user_id=388573 Ok. I'll start working on it on the next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-24 13:13 Message: Logged In: YES user_id=21627 I don't see it as a big problem, but I would not object much to a change. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 From noreply at sourceforge.net Tue Oct 28 01:22:29 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 01:22:34 2003 Subject: [Python-bugs-list] [ python-Bugs-827902 ] ctime is not creation time Message-ID: Bugs item #827902, was opened at 2003-10-21 19:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: ctime is not creation time Initial Comment: Hi! http://python.org/doc/current/lib/module-os.path.html says getctime() returns the creation time. But it probably returns the ctime, which has nothing to do with creation. Bye, Robert ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-28 01:22 Message: Logged In: YES user_id=80475 Hmm, it looks like there is more that one answer. >From Linux man pages: ctime is the "inode change time" >From MSDN specs: ctime "Indicates the creation time for this storage, stream, or byte array". We can either document both or just put that getctime returns the operating system's ctime field for open storage, a stream, or a byte-array. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-27 18:57 Message: Logged In: YES user_id=21627 So what about the issue that ctime really does mean "creation time" on Windows? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-27 15:05 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libposixpath.tex 1.37 and 1.36.12.1. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-23 03:14 Message: Logged In: YES user_id=887415 On Windows 2000 os.path.ctime (-> ntpath.getctime -> ntpath.stat.st_ctime) returns creation time. ---------------------------------------------------------------------- Comment By: Robert Siemer (siemer) Date: 2003-10-22 17:11 Message: Logged In: YES user_id=150699 ctime is the time of last modification of file status information. Means: gets updated on everything... (-: There is no way on classic Linux-Filesystems to get the creation time. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-22 16:14 Message: Logged In: YES user_id=43607 ctime is change time. Read the manual (stat(2)): time_t st_atime; /* time of last access */ time_t st_mtime; /* time of last modification */ time_t st_ctime; /* time of last change */ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-22 11:02 Message: Logged In: YES user_id=21627 Why do you say ctime has nothing to do with creation? What else does ctime indicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 From noreply at sourceforge.net Tue Oct 28 01:29:40 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 01:29:44 2003 Subject: [Python-bugs-list] [ python-Bugs-818059 ] os.listdir on empty strings. Inconsistent behaviour. Message-ID: Bugs item #818059, was opened at 2003-10-05 05:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818059&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hannu Kankaanp?? (hannukoo) Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir on empty strings. Inconsistent behaviour. Initial Comment: Behaviour tested in Python 2.3 (final) and 2.3.2 (final). os.listdir('') and os.listdir(u'') have very different behaviour across different OSes: WinXP/WinNT: os.listdir('') -- current dir (e.g. c:\python) os.listdir(u'') -- root dir (e.g. c:\) Win98 os.listdir('') -- root dir os.listdir(u'') -- root dir Redhat Linux 9.0 os.listdir('') -- OSError os.listdir(u'') -- OSError Particularly weird is the WinXP/WinNT behaviour that is different between unicode and normal strings. Suggestion for fix: Make os.listdir for empty strings always raise an exception or always list the current working directory. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-28 01:29 Message: Logged In: YES user_id=80475 Confirmed for WinME/98. Also, the behavior changed from Py2.2 where on WinME/98, it returned the root directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818059&group_id=5470 From noreply at sourceforge.net Tue Oct 28 01:31:43 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 01:31:48 2003 Subject: [Python-bugs-list] [ python-Bugs-818059 ] os.listdir on empty strings. Inconsistent behaviour. Message-ID: Bugs item #818059, was opened at 2003-10-05 05:50 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818059&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hannu Kankaanp?? (hannukoo) >Assigned to: Just van Rossum (jvr) Summary: os.listdir on empty strings. Inconsistent behaviour. Initial Comment: Behaviour tested in Python 2.3 (final) and 2.3.2 (final). os.listdir('') and os.listdir(u'') have very different behaviour across different OSes: WinXP/WinNT: os.listdir('') -- current dir (e.g. c:\python) os.listdir(u'') -- root dir (e.g. c:\) Win98 os.listdir('') -- root dir os.listdir(u'') -- root dir Redhat Linux 9.0 os.listdir('') -- OSError os.listdir(u'') -- OSError Particularly weird is the WinXP/WinNT behaviour that is different between unicode and normal strings. Suggestion for fix: Make os.listdir for empty strings always raise an exception or always list the current working directory. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-28 01:31 Message: Logged In: YES user_id=80475 Just, I believe this was your change. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-28 01:29 Message: Logged In: YES user_id=80475 Confirmed for WinME/98. Also, the behavior changed from Py2.2 where on WinME/98, it returned the root directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818059&group_id=5470 From noreply at sourceforge.net Tue Oct 28 01:53:44 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 01:53:52 2003 Subject: [Python-bugs-list] [ python-Bugs-831574 ] Solaris term.h needs curses.h Message-ID: Bugs item #831574, was opened at 2003-10-28 17: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=831574&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris term.h needs curses.h Initial Comment: Solaris' term.h requires curses.h to be included first. This causes the configure script to emit lines about a bug in autoconf. From the autoconf mailing lists, their standard response is to fix the configure script, see e.g. http://mail.gnu.org/archive/html/bug-autoconf/2003-05/msg00118.html The following patch against 2.3 branch for configure and configure.in makes things a bit happier. Note that Include/py_curses.h already includes curses.h before term.h, this just fixes the breakage of configure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831574&group_id=5470 From noreply at sourceforge.net Tue Oct 28 02:34:45 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 02:34:50 2003 Subject: [Python-bugs-list] [ python-Bugs-827190 ] wrong error message of islice indexing Message-ID: Bugs item #827190, was opened at 2003-10-20 17:46 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827190&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: wrong error message of islice indexing Initial Comment: If you pass negative values to itertools.islice, you get a wrong error message. Indices for itertools.islice() may be non-negative integers(zero is included), but the error message says that they must be positive. I think the message needs to be corrected. >>> from itertools import islice >>> l = range(5) >>> islice(l, 0, None) >>> islice(l, -1, None) Traceback (most recent call last): File "", line 1, in ? ValueError: Indices for islice() must be positive. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-28 02:34 Message: Logged In: YES user_id=80475 Fixed the error messages. See Modules/itertoolsmodule.c 1.25 ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-25 05:46 Message: Logged In: YES user_id=887415 Patch submitted. Error message changed to "Indices for islice() must be non-negative." Also fixed >>> islice('abc', -1). http://sourceforge.net/tracker/index.php? func=detail&aid=830070&group_id=5470&atid=305470 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827190&group_id=5470 From noreply at sourceforge.net Tue Oct 28 02:45:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 02:45:43 2003 Subject: [Python-bugs-list] [ python-Bugs-824854 ] dict.__init__ doesn't call subclass's __setitem__. Message-ID: Bugs item #824854, was opened at 2003-10-16 09:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824854&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Guido van Rossum (gvanrossum) Summary: dict.__init__ doesn't call subclass's __setitem__. Initial Comment: The easiest way to describe this is with the code I was using that uncovered this bug: class TwoWayDictionary(dict): __slots__ = () def __setitem__(self, key, value): dict.__setitem__(self, key, value) dict.__setitem__(self, value, key) I suspected this bug might happen, so I wrote this test: class TwoWayDictionaryTestCase(unittest.TestCase): def testInit(self): d = TwoWayDictionary(foo='bar') self.failUnless('foo' in d) self.failUnless('bar' in d) Basically, dict.__init__ is calling dict.__setitem__ even in subclasses. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-28 02:45 Message: Logged In: YES user_id=80475 This isn't a bug. Guido and I specifically discussed this for lists and arrived at the conclusion that the methods are to remain independent. If someone needs __init__ to change, they should override it also. In general, most objects do not have a promised set of kernel methods that propagate their effects to other methods. Internally, python is laced with code that accesses objects directly and cannot be reasonably converted. This independence of methods is both a feature and fact of life in the OOP world. This is especially true for objects where there is no universal agreement as to what the primitives are (quick, which is more basic, dict.has_key or dict.__contains__; should overriding one affect the other; should overriding dict.__getitem__ affect dict.has_key since that latter can be defined in terms of the former). As so it goes . . . ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-16 09:50 Message: Logged In: YES user_id=6656 I honestly don't know. I slightly doubt it. It would probably be PEP material. I wonder what Guido thinks... ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-16 09:41 Message: Logged In: YES user_id=99508 If someone went to the trouble to be able to define what "kermel methods" are used in the dict/list/whatever else implementations, would it even be accepted, or would it be considered too useless/slow/etc. to be bothered with? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-16 09:33 Message: Logged In: YES user_id=6656 .update() won't call TwoWayDictionary.__setitem__ either. Ditto .setdefault. You'll see similar behaviour for lists too. AFAIK, nowhere do the Python docs promise that the dictionary implementation is defined in terms of certain "primitive methods". You may think this a bug, but it's a whole lotta work to "fix" it. FWIW, you might be happier using UserDict.DictMixin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=824854&group_id=5470 From noreply at sourceforge.net Tue Oct 28 02:51:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 02:51:27 2003 Subject: [Python-bugs-list] [ python-Bugs-811898 ] int ("ffffffd3", 16) gives error Message-ID: Bugs item #811898, was opened at 2003-09-24 11:44 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811898&group_id=5470 Category: None Group: Python 2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Neal D. Becker (nbecker) Assigned to: Nobody/Anonymous (nobody) Summary: int ("ffffffd3", 16) gives error Initial Comment: Subject says it all. This should not give an error on a machine that uses 32-bit 2's complement representation for int. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-01 20:17 Message: Logged In: YES user_id=139865 ints in Python 2.2 on a 32 bit machine can only hold values from -(2 ** 31) to (2 ** 31) - 1. int() will not return a negative number without a minus sign, the opposite of what hex literals do. In Python 2.3, int('ffffffd3', 16) returns 4294967251L. In Python 2.4, 0xffffffd3 will mean 4294967251L. See PEP 237 for more information. Mark as invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811898&group_id=5470 From noreply at sourceforge.net Tue Oct 28 03:26:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 03:26:39 2003 Subject: [Python-bugs-list] [ python-Bugs-818059 ] os.listdir on empty strings. Inconsistent behaviour. Message-ID: Bugs item #818059, was opened at 2003-10-05 12:50 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818059&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Hannu Kankaanp?? (hannukoo) >Assigned to: Nobody/Anonymous (nobody) Summary: os.listdir on empty strings. Inconsistent behaviour. Initial Comment: Behaviour tested in Python 2.3 (final) and 2.3.2 (final). os.listdir('') and os.listdir(u'') have very different behaviour across different OSes: WinXP/WinNT: os.listdir('') -- current dir (e.g. c:\python) os.listdir(u'') -- root dir (e.g. c:\) Win98 os.listdir('') -- root dir os.listdir(u'') -- root dir Redhat Linux 9.0 os.listdir('') -- OSError os.listdir(u'') -- OSError Particularly weird is the WinXP/WinNT behaviour that is different between unicode and normal strings. Suggestion for fix: Make os.listdir for empty strings always raise an exception or always list the current working directory. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-10-28 09:26 Message: Logged In: YES user_id=92689 I didn't touch the Win side of os.listdir() (it already supported unicode strings), so I'm pretty sure it isn't. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-28 07:31 Message: Logged In: YES user_id=80475 Just, I believe this was your change. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-28 07:29 Message: Logged In: YES user_id=80475 Confirmed for WinME/98. Also, the behavior changed from Py2.2 where on WinME/98, it returned the root directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=818059&group_id=5470 From noreply at sourceforge.net Tue Oct 28 04:43:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 04:44:00 2003 Subject: [Python-bugs-list] [ python-Feature Requests-831643 ] Set option for subprocess in setup.py Message-ID: Feature Requests item #831643, was opened at 2003-10-28 10:43 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=831643&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Pim Buurman (pimbuur) Assigned to: Nobody/Anonymous (nobody) Summary: Set option for subprocess in setup.py Initial Comment: It is now only possible to prescribe options for subprocesses (e.g. build_ext) in the file setup.cfg But some of these options are obligatory to get the correct result for the action. These options can be set in the file setup.cfg, but it is not clear that these options should not be changed, nor is it clear in the setup.py file that the setup.cfg is relevant. I tend now to not to use the setup.cfg and call 'python setup.py' (without arguments). The setup.py will then fill in the necessary options in sys.argv . It would be much nicer if these options could be explicitly given as defaults for the subprocess. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=831643&group_id=5470 From noreply at sourceforge.net Tue Oct 28 07:11:38 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 07:12:43 2003 Subject: [Python-bugs-list] [ python-Bugs-793822 ] gc.get_referrers() is inherently dangerous Message-ID: Bugs item #793822, was opened at 2003-08-23 17:17 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793822&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: gc.get_referrers() is inherently dangerous Initial Comment: gc.get_referrers() can be used to crash any Python interpreter because it allows the user to obtain objects which are still under construction. Here is an example where an iterator can use it to obtain a tuple while it is still being populated by the 'tuple' built-in function. The following example triggers a SystemError, but as the tuple 't' is at the moment still full of null values it can easily generate segfaults instead. from gc import get_referrers def iter(): tag = object() yield tag # 'tag' gets stored in the result tuple lst = [x for x in get_referrers(tag) if isinstance(x, tuple)] t = lst[0] # this *is* the result tuple print t # full of nulls ! tuple(iter()) Unless someone has more ideas than me as to how to prevent this problem, I'd suggest that gc.get_referrers() should be deemed 'officially dangerous' in the docs. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2003-10-28 12:11 Message: Logged In: YES user_id=4771 Checked in: Doc/lib/libgc.tex (rev: 1.15) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-09-06 22:51 Message: Logged In: YES user_id=357491 The wording Armin proposes in his patch makes sense to me. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-09-02 18:11 Message: Logged In: YES user_id=4771 Here is the doc patch (attached). A clean solution to this problem would involve delaying GC registration, which I think would imply changes in the C API. It is probably not worth it. I don't think it would be a problem for the GC not to be able to browse through objects still under constructions because such objects are never part of a dead cycle anyway, and probably not part of a cycle at all until later mutated. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-08-31 23:36 Message: Logged In: YES user_id=31435 Martin, it's easy to transform the example into one that crashes. For example, adding "print t[3]" as the last line of the iter() function causes it to die with a segfault on my box. Virtually anything that fetches a NULL from the tuple will try to Py_INCREF it (that's all "t[3]" does), and that's an instant NULL-pointer dereferencing death. That said, it would be more helpful if Armin submitted a doc patch. The introspective features of the gc module are intended to be used by consenting adults facing hard debugging problems, and I don't care if they can be tricked into blowing up. I agree the docs should point out the possibility, though. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-08-31 17:18 Message: Logged In: YES user_id=21627 I see no harm in your example. Even though the tuple has NULLs in it, is in a stable state. The lesson learned is that an object should become gc-tracked only if it is in a stable state, as gc-tracking means to expose references to the object. This is true independent of get_referrers, as gc-tracking means that tp_traverse might be called for the object, so it *has* to be in a stable state. I fail to see how the example "crashes" the Python interpreter. I causes a SystemError when the tuple is resized, that's all. There are many ways to cause a SystemError, including raise SystemError I recommend not to declare a function as "dangerous" in the docs. Instead, the actual problem should be explained, both in the GC part of the C API, and in gc module docs (for both get_referrers, and get_objects). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-08-28 13:23 Message: Logged In: YES user_id=4771 But it would be very difficult to fix the code base to avoid the problem. The 'tuple' constructor was only an example; it is actually a quite common pattern everywhere in the C code base of both the core and extension modules. Expecting an object not to be seen before you first hand it out is extremely common, and get_referrers() breaks that assumption. Hence the claim that the problem really lies in get_referrers(). ---------------------------------------------------------------------- Comment By: Denis S. Otkidach (ods) Date: 2003-08-28 07:35 Message: Logged In: YES user_id=63454 I guess it's dangerous to make object that is not properly initialized reachable from other code. Even if it's reachable with get_referrers() only. There is no danger in get_referrers() itself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793822&group_id=5470 From noreply at sourceforge.net Tue Oct 28 07:17:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 07:18:08 2003 Subject: [Python-bugs-list] [ python-Bugs-811294 ] dis.disassemble_string() broken Message-ID: Bugs item #811294, was opened at 2003-09-23 17:23 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: dis.disassemble_string() broken Initial Comment: dis.disassemble_string(), called by dis.dis("some-bytecode-string"), still relies on the dead SET_LINENO opcode. I'll propose a patch for this at some later time. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2003-10-28 12:17 Message: Logged In: YES user_id=4771 findlinestarts() not documented. Its docstring should be enough to interest people that want to play with co_lnotab. Checked in: Lib/dis.py (rev: 1.47) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-10-16 13:16 Message: Logged In: YES user_id=4771 Do we want findlinestarts() to be added to the public interface of dis? I think it is a generally useful tool (e.g. it could be used in trace.py too, though I don't understand trace.py well enough to know if the easy patch does exactly what is expected). I can write a doc patch if the answer is yes. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-16 12:55 Message: Logged In: YES user_id=6656 I think I trust Armin on stuff like this ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-09-26 11:07 Message: Logged In: YES user_id=4771 Here is a patch with a separate generator function that enumerates all (offset, lineno) pairs, as they where in the compiler before they got obfuscated into lnotab. For simplicity, disassemble() just turns them into a dict, so it didn't really have to be a generator at all, but it is just nicer this way. Maybe pdb could use it too. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2003-09-26 10:20 Message: Logged In: YES user_id=4771 ah well. I didn't realize that disassemble_string() never tried to *display* line numbers. It only detects SET_LINENO so that it can write a nice blank line before it. Attached a patch that removes this behavior (no longer possible in a function that doesn't have access to a co_lnotab). I'll submit another more constructive patch anyway, in which I try to factor out the subtle decoding algorithm for co_lnotabs into an easy-to-use generator. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811294&group_id=5470 From noreply at sourceforge.net Tue Oct 28 08:08:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 08:09:08 2003 Subject: [Python-bugs-list] [ python-Bugs-831574 ] Solaris term.h needs curses.h Message-ID: Bugs item #831574, was opened at 2003-10-28 01:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831574&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Martin v. L?wis (loewis) Summary: Solaris term.h needs curses.h Initial Comment: Solaris' term.h requires curses.h to be included first. This causes the configure script to emit lines about a bug in autoconf. From the autoconf mailing lists, their standard response is to fix the configure script, see e.g. http://mail.gnu.org/archive/html/bug-autoconf/2003-05/msg00118.html The following patch against 2.3 branch for configure and configure.in makes things a bit happier. Note that Include/py_curses.h already includes curses.h before term.h, this just fixes the breakage of configure. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-28 08:08 Message: Logged In: YES user_id=33168 Should the #if be an #ifdef ? Looks fine to me, but I don't know much about autoconf. :-) I think Martin is the expert. Martin do you have an opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831574&group_id=5470 From noreply at sourceforge.net Tue Oct 28 08:38:13 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 08:38:26 2003 Subject: [Python-bugs-list] [ python-Bugs-831747 ] httplib hardcodes Accept-Encoding Message-ID: Bugs item #831747, was opened at 2003-10-28 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=831747&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: httplib hardcodes Accept-Encoding Initial Comment: in httplib.py the request() method adds a hardcoded Accept-Encoding header with the 'identity' value. This should at least be optional, since I have several programs supporting encodings like 'gzip' or 'deflate' and I want to be able to specify my own Accept-Encoding header. I suggest adding (similar to skip_host) a skip_accept_encoding optional argument. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831747&group_id=5470 From noreply at sourceforge.net Tue Oct 28 09:22:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 09:22:36 2003 Subject: [Python-bugs-list] [ python-Bugs-829458 ] setattr(obj, BADNAME, value) does not raises exception Message-ID: Bugs item #829458, was opened at 2003-10-24 11:53 Message generated for change (Comment added) made by hdima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: setattr(obj, BADNAME, value) does not raises exception Initial Comment: Now I just realize that setattr() does not check value of the name argument but simply insert the named value in __dict__ so setattr(obj, BADNAME, value) not equal to obj.BADNAME = value. It's true for new and old style classes and all python versions which I have tried (1.5, 2.1, 2.2, 2.3). Should not setattr(obj, BADNAME, value) raise appropriate exception (AttributeError or maybe ValueError)? For example: >>> class Test: pass ... >>> o = Test() >>> setattr(o, "test.test", 100) >>> setattr(o, "12345", 200) >>> dir(o) ['12345', '__doc__', '__module__', 'test.test'] ---------------------------------------------------------------------- >Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-28 17:22 Message: Logged In: YES user_id=388573 I don't know why setattr() should allows *any* attribute name, but if so shouldn't this ability will be documented at least? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-10-28 05:29 Message: Logged In: YES user_id=357491 I am going to argue for "no" on this one. The major point of setattr is that it allows you to set an attribute for *any* name after compile time. This should go for even attribute names that would not normally work. It is a rather powerful ability that I think should stay. Anyone else care to weigh in on this? ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-10-28 04:00 Message: Logged In: YES user_id=539787 Note: there is a valid_identifier function in Objects/typeobject.c which is being used by the __slots__ mechanism and I believe is quite handy; however, it is declared as static. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-26 12:09 Message: Logged In: YES user_id=388573 Give me some use case examples. Maybe you use object's __dict__ like general purpose dictionary? If so, it seems ugly for me. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-10-25 17:50 Message: Logged In: YES user_id=11105 Hm, you mean setattr() should only accept strings containing valid Python identifiers as the second argument, and choke on something like "123" or "a.b.c.d"? I would strongly object to this change, in fact I'm using it quite often. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-10-25 15:54 Message: Logged In: YES user_id=388573 Ok. I'll start working on it on the next week. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-25 00:13 Message: Logged In: YES user_id=21627 I don't see it as a big problem, but I would not object much to a change. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829458&group_id=5470 From noreply at sourceforge.net Tue Oct 28 12:35:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 12:35:58 2003 Subject: [Python-bugs-list] [ python-Bugs-827902 ] ctime is not creation time Message-ID: Bugs item #827902, was opened at 2003-10-21 19:32 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: ctime is not creation time Initial Comment: Hi! http://python.org/doc/current/lib/module-os.path.html says getctime() returns the creation time. But it probably returns the ctime, which has nothing to do with creation. Bye, Robert ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-28 01:22 Message: Logged In: YES user_id=80475 Hmm, it looks like there is more that one answer. >From Linux man pages: ctime is the "inode change time" >From MSDN specs: ctime "Indicates the creation time for this storage, stream, or byte array". We can either document both or just put that getctime returns the operating system's ctime field for open storage, a stream, or a byte-array. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-27 18:57 Message: Logged In: YES user_id=21627 So what about the issue that ctime really does mean "creation time" on Windows? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-27 15:05 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libposixpath.tex 1.37 and 1.36.12.1. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-23 03:14 Message: Logged In: YES user_id=887415 On Windows 2000 os.path.ctime (-> ntpath.getctime -> ntpath.stat.st_ctime) returns creation time. ---------------------------------------------------------------------- Comment By: Robert Siemer (siemer) Date: 2003-10-22 17:11 Message: Logged In: YES user_id=150699 ctime is the time of last modification of file status information. Means: gets updated on everything... (-: There is no way on classic Linux-Filesystems to get the creation time. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-22 16:14 Message: Logged In: YES user_id=43607 ctime is change time. Read the manual (stat(2)): time_t st_atime; /* time of last access */ time_t st_mtime; /* time of last modification */ time_t st_ctime; /* time of last change */ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-22 11:02 Message: Logged In: YES user_id=21627 Why do you say ctime has nothing to do with creation? What else does ctime indicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 From noreply at sourceforge.net Tue Oct 28 15:26:34 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 15:26:45 2003 Subject: [Python-bugs-list] [ python-Bugs-827902 ] ctime is not creation time Message-ID: Bugs item #827902, was opened at 2003-10-22 02:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: ctime is not creation time Initial Comment: Hi! http://python.org/doc/current/lib/module-os.path.html says getctime() returns the creation time. But it probably returns the ctime, which has nothing to do with creation. Bye, Robert ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-28 21:26 Message: Logged In: YES user_id=21627 I suggest to document all of these: it returns the system's ctime, which, on some systems (e.g. Unix) is change time, and, on others (e.g. Windows), is creation time. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-28 07:22 Message: Logged In: YES user_id=80475 Hmm, it looks like there is more that one answer. >From Linux man pages: ctime is the "inode change time" >From MSDN specs: ctime "Indicates the creation time for this storage, stream, or byte array". We can either document both or just put that getctime returns the operating system's ctime field for open storage, a stream, or a byte-array. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-28 00:57 Message: Logged In: YES user_id=21627 So what about the issue that ctime really does mean "creation time" on Windows? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-27 21:05 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libposixpath.tex 1.37 and 1.36.12.1. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-23 10:14 Message: Logged In: YES user_id=887415 On Windows 2000 os.path.ctime (-> ntpath.getctime -> ntpath.stat.st_ctime) returns creation time. ---------------------------------------------------------------------- Comment By: Robert Siemer (siemer) Date: 2003-10-23 00:11 Message: Logged In: YES user_id=150699 ctime is the time of last modification of file status information. Means: gets updated on everything... (-: There is no way on classic Linux-Filesystems to get the creation time. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-22 23:14 Message: Logged In: YES user_id=43607 ctime is change time. Read the manual (stat(2)): time_t st_atime; /* time of last access */ time_t st_mtime; /* time of last modification */ time_t st_ctime; /* time of last change */ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-22 18:02 Message: Logged In: YES user_id=21627 Why do you say ctime has nothing to do with creation? What else does ctime indicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 From noreply at sourceforge.net Tue Oct 28 16:12:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 16:13:04 2003 Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball Message-ID: Bugs item #728051, was opened at 2003-04-26 10:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Neal Norwitz (nnorwitz) Summary: Test failures on Linux, Python 2.3b1 tarball Initial Comment: "make test" resulted in: test test_tempfile failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure test test_time failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/admin/Python-2.3b1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-28 16:12 Message: Logged In: YES user_id=33168 What's the status of this bug? Is it still an issue or can it be closed? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-06-29 20:47 Message: Logged In: YES user_id=46639 I've re-uploaded the tzset configure.in patch as: http://www.python.org/sf/728051 The version in this bug report looks mangled. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-06-15 21:58 Message: Logged In: YES user_id=56214 Here are the gory details of the tempfile test: [admin@pilot Python-2.3b1]$ ./python -c "from test import test_tempfile; test_tempfile.test_main()" test_exports (test.test_tempfile.test_exports) ... ok test_get_six_char_str (test.test_tempfile.test__RandomNameSequence) ... ok test_many (test.test_tempfile.test__RandomNameSequence) ... ok test_supports_iter (test.test_tempfile.test__RandomNameSequence) ... ok test_nonempty_list (test.test_tempfile.test__candidate_tempdir_list) ... ok test_wanted_dirs (test.test_tempfile.test__candidate_tempdir_list) ... ok test_retval (test.test_tempfile.test__get_candidate_names) ... ok test_same_thing (test.test_tempfile.test__get_candidate_names) ... ok test_basic (test.test_tempfile.test__mkstemp_inner) ... ok test_basic_many (test.test_tempfile.test__mkstemp_inner) ... ok test_choose_directory (test.test_tempfile.test__mkstemp_inner) ... ok test_file_mode (test.test_tempfile.test__mkstemp_inner) ... ok fd 3 is open in childtest_noinherit (test.test_tempfile.test__mkstemp_inner) ... FAIL test_textmode (test.test_tempfile.test__mkstemp_inner) ... ok test_sane_template (test.test_tempfile.test_gettempprefix) ... ok test_usable_template (test.test_tempfile.test_gettempprefix) ... ok test_directory_exists (test.test_tempfile.test_gettempdir) ... ok test_directory_writable (test.test_tempfile.test_gettempdir) ... ok test_same_thing (test.test_tempfile.test_gettempdir) ... ok test_basic (test.test_tempfile.test_mkstemp) ... ok test_choose_directory (test.test_tempfile.test_mkstemp) ... ok test_basic (test.test_tempfile.test_mkdtemp) ... ok test_basic_many (test.test_tempfile.test_mkdtemp) ... ok test_choose_directory (test.test_tempfile.test_mkdtemp) ... ok test_mode (test.test_tempfile.test_mkdtemp) ... ok test_basic (test.test_tempfile.test_mktemp) ... ok test_many (test.test_tempfile.test_mktemp) ... ok test_basic (test.test_tempfile.test_NamedTemporaryFile) ... ok test_creates_named (test.test_tempfile.test_NamedTemporaryFile) ... ok test_del_on_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_basic (test.test_tempfile.test_TemporaryFile) ... ok test_has_no_name (test.test_tempfile.test_TemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_TemporaryFile) ... ok ====================================================================== FAIL: test_noinherit (test.test_tempfile.test__mkstemp_inner) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure ---------------------------------------------------------------------- Ran 34 tests in 0.217s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 651, in test_main test_support.run_suite(suite) File "/home/admin/Python-2.3b1/Lib/test/test_support.py", line 229, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-06-15 20:53 Message: Logged In: YES user_id=46639 Hmm... no file upload button for me in this topic. Here is a configure.in patch which should stop time.tzset being build on Redhat 6, and other platforms with this 'problem' (being that although tzset() may do something useful, it doesn't do what is documented or called multiple times by the same process) Index: dist/src/configure.in ======================================= ============================ RCS file: /cvsroot/python/python/dist/src/configure.in,v retrieving revision 1.418 diff -c -c -r1.418 configure.in *** dist/src/configure.in 14 Jun 2003 21:03:05 -0000 1.418 --- dist/src/configure.in 16 Jun 2003 00:43:24 -0000 *************** *** 2706,2723 **** #include int main() { int gmt_hour; int eastern_hour; ! time_t now; ! now = time((time_t*)NULL); putenv("TZ=UTC+0"); tzset(); ! gmt_hour = localtime(&now)->tm_hour; putenv("TZ=EST+5EDT,M4.1.0,M10.5.0"); tzset(); ! eastern_hour = localtime(&now)->tm_hour; ! if (eastern_hour == gmt_hour) exit(1); exit(0); } ], --- 2706,2737 ---- #include int main() { + /* Note that we need to ensure that not only does tzset(3) + do 'something' with localtime, but it works as documented + in the library reference and as expected by the test suite. */ int gmt_hour; int eastern_hour; ! int aus_hour; ! time_t xmas = 1040774400; ! putenv("TZ=UTC+0"); tzset(); ! gmt_hour = localtime(&xmas)->tm_hour; ! if (gmt_hour != 0) ! exit(1); ! putenv("TZ=EST+5EDT,M4.1.0,M10.5.0"); tzset(); ! eastern_hour = localtime(&xmas)->tm_hour; ! if (eastern_hour != 19) ! exit(1); ! ! putenv("TZ=AEST-10AEDT-11,M10.5.0,M3.5.0"); ! tzset(); ! aus_hour = localtime(&xmas)->tm_hour; ! if (aus_hour != 11) exit(1); + exit(0); } ], ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-10 20:42 Message: Logged In: YES user_id=357491 Sure thing. =) Execute this line from a terminal: python2.3 -c "from test import test_tempfile; test_tempfile.test_main()" All it is doing is importing the test_tempfile module from the test package and then executing test_tempfile.test_main() which runs all the tests. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-06-10 18:56 Message: Logged In: YES user_id=56214 I don't know. Tell me how to run the test on its own, and I'll tell you. :) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-10 18:04 Message: Logged In: YES user_id=357491 How about the test_tempfile failure? Does that occur when you run the test on its own? ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-05-25 09:21 Message: Logged In: YES user_id=56214 Here's the tz info; I'll email you the 'man tzset' separately. [admin@pilot Python-2.3a1]$ ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3a1]$ env TZ='US/Eastern' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3a1]$ env TZ='Australia/Melbourne' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EST') -36000 -39600 [admin@pilot Python-2.3a1]$ cd ../Python-2.3b1 [admin@pilot Python-2.3b1]$ ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3b1]$ env TZ='US/Eastern' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3b1]$ env TZ='Australia/Melbourne' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EST') -36000 -39600 [ ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-05-21 20:41 Message: Logged In: YES user_id=46639 This is from my patch. Phillip - can you please upload a copy of 'man tzset' on that Redhat box or email it to zen@shangri-la.dropbear.id.au. I'd also like to see the output of: python -c 'import time;print time.tzname,time.timezone,time.altzone' env TZ='US/Eastern' python -c 'import time;print time.tzname,time.timezone,time.altzone' env TZ='Australia/Melbourne' python -c 'import time;print time.tzname,time.timezone,time.altzone' I'm thinking that tzset(3) and the time libraries are not fully functional on this earlier version of Redhat, possibly by not handling southern hemisphere daylight savings. If so, it needs to be detected during configuration. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 11:00 Message: Logged In: YES user_id=21627 Neal, it appears you have checked in the test for the AEST zone. Can you analyse the test_time failure in more detail? ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-05-04 09:19 Message: Logged In: YES user_id=56214 It's an ISP-supplied variant of RedHat 6.2. I see 'libc-2.1.3.so' in the /lib directory, so I assume that's the version. Running 'strings' on it, I find: GNU C Library stable release version 2.1.3, by Roland McGrath et al. Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07. Available extensions: GNU libio by Per Bothner The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others BIND-4.9.7-REL NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton linuxthreads-0.8 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Python identifies itself as: Python 2.3b1 (#1, Apr 26 2003, 10:02:40) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 I just tested 2.3a1 andr 2.3a2 to confirm where the errors began. 2.3a1 doesn't show either error. 2.3a2 has the tempfile problem, but not the time problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 08:42 Message: Logged In: YES user_id=21627 What operating system distribution specifically did you use? What C library does this system use? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 From noreply at sourceforge.net Tue Oct 28 16:22:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 16:22:58 2003 Subject: [Python-bugs-list] [ python-Bugs-789402 ] Memory leak on open() only in 2.3? Message-ID: Bugs item #789402, was opened at 2003-08-15 14:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: David Lambert (jdalambert) Assigned to: Neal Norwitz (nnorwitz) Summary: Memory leak on open() only in 2.3? Initial Comment: If for instance /tmp is a directory, then the follwing code fragment produces a large memory leak on Python 2.3 compiled on Linux 2.4.20. This does not appear to be a problem with previous versions of the interpreter. #!/usr/local/bin/python while 1: try: open('/tmp') except: pass It appears that the exception IOError: [Error 21] Is a directory leave garbage. If the parameter to open() does not exist, the problem does not occur. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-28 16:22 Message: Logged In: YES user_id=33168 Backport was made as Objects/fileobject.c 2.179.8.3 on 2003/09/16 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-09-15 14:34 Message: Logged In: YES user_id=33168 No, I haven't had time to setup 2.3 branch in my cvs, test, and check in. Feel free to take it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-09-15 14:30 Message: Logged In: YES user_id=80475 Did this fix get backported yet? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-09-06 19:10 Message: Logged In: YES user_id=357491 Maybe? =) I just did a quick check and PyErr_SetObject (in Python/errors.c) calls PyErr_Restore in the same file that uses the 'value' argument to set the current PyThreadState's curexc_value which holds a PyObject. But there are so many places where PyThreadState is used I don't feel up to hunting down where it might cause an issue. Perhaps with more knowledge of the exception framework can answer the question. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2003-08-19 16:17 Message: Logged In: YES user_id=845425 Good point, but if PyObject_CallFunction fails, is PyErr_SetObject safe with a NULL second parameter? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-19 15:12 Message: Logged In: YES user_id=33168 Your fix is the same as what I checked in, except that I used Py_XDECREF instead of Py_DECREF, since PyObject_CallFunction could fail and return NULL. This still needs a test and backport to 2.3.1. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2003-08-19 09:52 Message: Logged In: YES user_id=845425 Over the weekend and through Monday I ran my system 24/7 with the previously attached code. There do not seem to be any problems, but I am waiting for your "blessing" before considering it a fix. ---------------------------------------------------------------------- Comment By: David Lambert (jdalambert) Date: 2003-08-16 19:09 Message: Logged In: YES user_id=845425 I think I may have a fix. Check out the attached file. It seems to work for me. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-08-15 16:07 Message: Logged In: YES user_id=33168 Wow, it sure does leak! Checked in as: Objects/fileobject.c 2.180 Still needs a test. Leaving open until I get around to it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789402&group_id=5470 From noreply at sourceforge.net Tue Oct 28 16:48:46 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 16:48:50 2003 Subject: [Python-bugs-list] [ python-Bugs-831969 ] Docstring for pyclbr.readmodule() is incorrect Message-ID: Bugs item #831969, was opened at 2003-10-28 16: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=831969&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jeff Grimmett (grimmtooth) Assigned to: Nobody/Anonymous (nobody) Summary: Docstring for pyclbr.readmodule() is incorrect Initial Comment: Review of source code for pyclbr.readmodule() reveals the following: '''Backwards compatible interface. Call readmodule_ex() and then only keep Class objects from the resulting dictionary.''' However, the function actually calls pyclbr._readmodule (): dict = _readmodule(module, path) (around line 81 of pyclbr.py) It *appears* that the code is good and that the docstring just needs adjusted. (py v. 2.3.1, Win2K 5.00.2195) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831969&group_id=5470 From noreply at sourceforge.net Tue Oct 28 17:23:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 17:24:03 2003 Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball Message-ID: Bugs item #728051, was opened at 2003-04-26 14:23 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Neal Norwitz (nnorwitz) Summary: Test failures on Linux, Python 2.3b1 tarball Initial Comment: "make test" resulted in: test test_tempfile failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure test test_time failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/admin/Python-2.3b1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2003-10-28 22:23 Message: Logged In: YES user_id=56214 All tests pass as of Python 2.3.2, so this bug can be closed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-28 21:12 Message: Logged In: YES user_id=33168 What's the status of this bug? Is it still an issue or can it be closed? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-06-30 00:47 Message: Logged In: YES user_id=46639 I've re-uploaded the tzset configure.in patch as: http://www.python.org/sf/728051 The version in this bug report looks mangled. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-06-16 01:58 Message: Logged In: YES user_id=56214 Here are the gory details of the tempfile test: [admin@pilot Python-2.3b1]$ ./python -c "from test import test_tempfile; test_tempfile.test_main()" test_exports (test.test_tempfile.test_exports) ... ok test_get_six_char_str (test.test_tempfile.test__RandomNameSequence) ... ok test_many (test.test_tempfile.test__RandomNameSequence) ... ok test_supports_iter (test.test_tempfile.test__RandomNameSequence) ... ok test_nonempty_list (test.test_tempfile.test__candidate_tempdir_list) ... ok test_wanted_dirs (test.test_tempfile.test__candidate_tempdir_list) ... ok test_retval (test.test_tempfile.test__get_candidate_names) ... ok test_same_thing (test.test_tempfile.test__get_candidate_names) ... ok test_basic (test.test_tempfile.test__mkstemp_inner) ... ok test_basic_many (test.test_tempfile.test__mkstemp_inner) ... ok test_choose_directory (test.test_tempfile.test__mkstemp_inner) ... ok test_file_mode (test.test_tempfile.test__mkstemp_inner) ... ok fd 3 is open in childtest_noinherit (test.test_tempfile.test__mkstemp_inner) ... FAIL test_textmode (test.test_tempfile.test__mkstemp_inner) ... ok test_sane_template (test.test_tempfile.test_gettempprefix) ... ok test_usable_template (test.test_tempfile.test_gettempprefix) ... ok test_directory_exists (test.test_tempfile.test_gettempdir) ... ok test_directory_writable (test.test_tempfile.test_gettempdir) ... ok test_same_thing (test.test_tempfile.test_gettempdir) ... ok test_basic (test.test_tempfile.test_mkstemp) ... ok test_choose_directory (test.test_tempfile.test_mkstemp) ... ok test_basic (test.test_tempfile.test_mkdtemp) ... ok test_basic_many (test.test_tempfile.test_mkdtemp) ... ok test_choose_directory (test.test_tempfile.test_mkdtemp) ... ok test_mode (test.test_tempfile.test_mkdtemp) ... ok test_basic (test.test_tempfile.test_mktemp) ... ok test_many (test.test_tempfile.test_mktemp) ... ok test_basic (test.test_tempfile.test_NamedTemporaryFile) ... ok test_creates_named (test.test_tempfile.test_NamedTemporaryFile) ... ok test_del_on_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_basic (test.test_tempfile.test_TemporaryFile) ... ok test_has_no_name (test.test_tempfile.test_TemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_TemporaryFile) ... ok ====================================================================== FAIL: test_noinherit (test.test_tempfile.test__mkstemp_inner) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure ---------------------------------------------------------------------- Ran 34 tests in 0.217s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 651, in test_main test_support.run_suite(suite) File "/home/admin/Python-2.3b1/Lib/test/test_support.py", line 229, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-06-16 00:53 Message: Logged In: YES user_id=46639 Hmm... no file upload button for me in this topic. Here is a configure.in patch which should stop time.tzset being build on Redhat 6, and other platforms with this 'problem' (being that although tzset() may do something useful, it doesn't do what is documented or called multiple times by the same process) Index: dist/src/configure.in ======================================= ============================ RCS file: /cvsroot/python/python/dist/src/configure.in,v retrieving revision 1.418 diff -c -c -r1.418 configure.in *** dist/src/configure.in 14 Jun 2003 21:03:05 -0000 1.418 --- dist/src/configure.in 16 Jun 2003 00:43:24 -0000 *************** *** 2706,2723 **** #include int main() { int gmt_hour; int eastern_hour; ! time_t now; ! now = time((time_t*)NULL); putenv("TZ=UTC+0"); tzset(); ! gmt_hour = localtime(&now)->tm_hour; putenv("TZ=EST+5EDT,M4.1.0,M10.5.0"); tzset(); ! eastern_hour = localtime(&now)->tm_hour; ! if (eastern_hour == gmt_hour) exit(1); exit(0); } ], --- 2706,2737 ---- #include int main() { + /* Note that we need to ensure that not only does tzset(3) + do 'something' with localtime, but it works as documented + in the library reference and as expected by the test suite. */ int gmt_hour; int eastern_hour; ! int aus_hour; ! time_t xmas = 1040774400; ! putenv("TZ=UTC+0"); tzset(); ! gmt_hour = localtime(&xmas)->tm_hour; ! if (gmt_hour != 0) ! exit(1); ! putenv("TZ=EST+5EDT,M4.1.0,M10.5.0"); tzset(); ! eastern_hour = localtime(&xmas)->tm_hour; ! if (eastern_hour != 19) ! exit(1); ! ! putenv("TZ=AEST-10AEDT-11,M10.5.0,M3.5.0"); ! tzset(); ! aus_hour = localtime(&xmas)->tm_hour; ! if (aus_hour != 11) exit(1); + exit(0); } ], ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-11 00:42 Message: Logged In: YES user_id=357491 Sure thing. =) Execute this line from a terminal: python2.3 -c "from test import test_tempfile; test_tempfile.test_main()" All it is doing is importing the test_tempfile module from the test package and then executing test_tempfile.test_main() which runs all the tests. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-06-10 22:56 Message: Logged In: YES user_id=56214 I don't know. Tell me how to run the test on its own, and I'll tell you. :) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-10 22:04 Message: Logged In: YES user_id=357491 How about the test_tempfile failure? Does that occur when you run the test on its own? ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-05-25 13:21 Message: Logged In: YES user_id=56214 Here's the tz info; I'll email you the 'man tzset' separately. [admin@pilot Python-2.3a1]$ ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3a1]$ env TZ='US/Eastern' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3a1]$ env TZ='Australia/Melbourne' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EST') -36000 -39600 [admin@pilot Python-2.3a1]$ cd ../Python-2.3b1 [admin@pilot Python-2.3b1]$ ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3b1]$ env TZ='US/Eastern' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3b1]$ env TZ='Australia/Melbourne' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EST') -36000 -39600 [ ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-05-22 00:41 Message: Logged In: YES user_id=46639 This is from my patch. Phillip - can you please upload a copy of 'man tzset' on that Redhat box or email it to zen@shangri-la.dropbear.id.au. I'd also like to see the output of: python -c 'import time;print time.tzname,time.timezone,time.altzone' env TZ='US/Eastern' python -c 'import time;print time.tzname,time.timezone,time.altzone' env TZ='Australia/Melbourne' python -c 'import time;print time.tzname,time.timezone,time.altzone' I'm thinking that tzset(3) and the time libraries are not fully functional on this earlier version of Redhat, possibly by not handling southern hemisphere daylight savings. If so, it needs to be detected during configuration. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 15:00 Message: Logged In: YES user_id=21627 Neal, it appears you have checked in the test for the AEST zone. Can you analyse the test_time failure in more detail? ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-05-04 13:19 Message: Logged In: YES user_id=56214 It's an ISP-supplied variant of RedHat 6.2. I see 'libc-2.1.3.so' in the /lib directory, so I assume that's the version. Running 'strings' on it, I find: GNU C Library stable release version 2.1.3, by Roland McGrath et al. Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07. Available extensions: GNU libio by Per Bothner The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others BIND-4.9.7-REL NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton linuxthreads-0.8 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Python identifies itself as: Python 2.3b1 (#1, Apr 26 2003, 10:02:40) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 I just tested 2.3a1 andr 2.3a2 to confirm where the errors began. 2.3a1 doesn't show either error. 2.3a2 has the tempfile problem, but not the time problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 12:42 Message: Logged In: YES user_id=21627 What operating system distribution specifically did you use? What C library does this system use? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 From noreply at sourceforge.net Tue Oct 28 17:24:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 17:24:35 2003 Subject: [Python-bugs-list] [ python-Bugs-728051 ] Test failures on Linux, Python 2.3b1 tarball Message-ID: Bugs item #728051, was opened at 2003-04-26 14:23 Message generated for change (Settings changed) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 Category: Build Group: Python 2.3 Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Neal Norwitz (nnorwitz) Summary: Test failures on Linux, Python 2.3b1 tarball Initial Comment: "make test" resulted in: test test_tempfile failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure test test_time failed -- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/admin/Python-2.3b1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-10-28 22:23 Message: Logged In: YES user_id=56214 All tests pass as of Python 2.3.2, so this bug can be closed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-28 21:12 Message: Logged In: YES user_id=33168 What's the status of this bug? Is it still an issue or can it be closed? ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-06-30 00:47 Message: Logged In: YES user_id=46639 I've re-uploaded the tzset configure.in patch as: http://www.python.org/sf/728051 The version in this bug report looks mangled. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-06-16 01:58 Message: Logged In: YES user_id=56214 Here are the gory details of the tempfile test: [admin@pilot Python-2.3b1]$ ./python -c "from test import test_tempfile; test_tempfile.test_main()" test_exports (test.test_tempfile.test_exports) ... ok test_get_six_char_str (test.test_tempfile.test__RandomNameSequence) ... ok test_many (test.test_tempfile.test__RandomNameSequence) ... ok test_supports_iter (test.test_tempfile.test__RandomNameSequence) ... ok test_nonempty_list (test.test_tempfile.test__candidate_tempdir_list) ... ok test_wanted_dirs (test.test_tempfile.test__candidate_tempdir_list) ... ok test_retval (test.test_tempfile.test__get_candidate_names) ... ok test_same_thing (test.test_tempfile.test__get_candidate_names) ... ok test_basic (test.test_tempfile.test__mkstemp_inner) ... ok test_basic_many (test.test_tempfile.test__mkstemp_inner) ... ok test_choose_directory (test.test_tempfile.test__mkstemp_inner) ... ok test_file_mode (test.test_tempfile.test__mkstemp_inner) ... ok fd 3 is open in childtest_noinherit (test.test_tempfile.test__mkstemp_inner) ... FAIL test_textmode (test.test_tempfile.test__mkstemp_inner) ... ok test_sane_template (test.test_tempfile.test_gettempprefix) ... ok test_usable_template (test.test_tempfile.test_gettempprefix) ... ok test_directory_exists (test.test_tempfile.test_gettempdir) ... ok test_directory_writable (test.test_tempfile.test_gettempdir) ... ok test_same_thing (test.test_tempfile.test_gettempdir) ... ok test_basic (test.test_tempfile.test_mkstemp) ... ok test_choose_directory (test.test_tempfile.test_mkstemp) ... ok test_basic (test.test_tempfile.test_mkdtemp) ... ok test_basic_many (test.test_tempfile.test_mkdtemp) ... ok test_choose_directory (test.test_tempfile.test_mkdtemp) ... ok test_mode (test.test_tempfile.test_mkdtemp) ... ok test_basic (test.test_tempfile.test_mktemp) ... ok test_many (test.test_tempfile.test_mktemp) ... ok test_basic (test.test_tempfile.test_NamedTemporaryFile) ... ok test_creates_named (test.test_tempfile.test_NamedTemporaryFile) ... ok test_del_on_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_basic (test.test_tempfile.test_TemporaryFile) ... ok test_has_no_name (test.test_tempfile.test_TemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_TemporaryFile) ... ok ====================================================================== FAIL: test_noinherit (test.test_tempfile.test__mkstemp_inner) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure ---------------------------------------------------------------------- Ran 34 tests in 0.217s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 651, in test_main test_support.run_suite(suite) File "/home/admin/Python-2.3b1/Lib/test/test_support.py", line 229, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/home/admin/Python-2.3b1/Lib/test/test_tempfile.py", line 299, in test_noinherit self.failIf(retval > 0, "child process reports failure") File "/home/admin/Python-2.3b1/Lib/unittest.py", line 264, in failIf if expr: raise self.failureException, msg AssertionError: child process reports failure ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-06-16 00:53 Message: Logged In: YES user_id=46639 Hmm... no file upload button for me in this topic. Here is a configure.in patch which should stop time.tzset being build on Redhat 6, and other platforms with this 'problem' (being that although tzset() may do something useful, it doesn't do what is documented or called multiple times by the same process) Index: dist/src/configure.in ======================================= ============================ RCS file: /cvsroot/python/python/dist/src/configure.in,v retrieving revision 1.418 diff -c -c -r1.418 configure.in *** dist/src/configure.in 14 Jun 2003 21:03:05 -0000 1.418 --- dist/src/configure.in 16 Jun 2003 00:43:24 -0000 *************** *** 2706,2723 **** #include int main() { int gmt_hour; int eastern_hour; ! time_t now; ! now = time((time_t*)NULL); putenv("TZ=UTC+0"); tzset(); ! gmt_hour = localtime(&now)->tm_hour; putenv("TZ=EST+5EDT,M4.1.0,M10.5.0"); tzset(); ! eastern_hour = localtime(&now)->tm_hour; ! if (eastern_hour == gmt_hour) exit(1); exit(0); } ], --- 2706,2737 ---- #include int main() { + /* Note that we need to ensure that not only does tzset(3) + do 'something' with localtime, but it works as documented + in the library reference and as expected by the test suite. */ int gmt_hour; int eastern_hour; ! int aus_hour; ! time_t xmas = 1040774400; ! putenv("TZ=UTC+0"); tzset(); ! gmt_hour = localtime(&xmas)->tm_hour; ! if (gmt_hour != 0) ! exit(1); ! putenv("TZ=EST+5EDT,M4.1.0,M10.5.0"); tzset(); ! eastern_hour = localtime(&xmas)->tm_hour; ! if (eastern_hour != 19) ! exit(1); ! ! putenv("TZ=AEST-10AEDT-11,M10.5.0,M3.5.0"); ! tzset(); ! aus_hour = localtime(&xmas)->tm_hour; ! if (aus_hour != 11) exit(1); + exit(0); } ], ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-11 00:42 Message: Logged In: YES user_id=357491 Sure thing. =) Execute this line from a terminal: python2.3 -c "from test import test_tempfile; test_tempfile.test_main()" All it is doing is importing the test_tempfile module from the test package and then executing test_tempfile.test_main() which runs all the tests. ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-06-10 22:56 Message: Logged In: YES user_id=56214 I don't know. Tell me how to run the test on its own, and I'll tell you. :) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-10 22:04 Message: Logged In: YES user_id=357491 How about the test_tempfile failure? Does that occur when you run the test on its own? ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-05-25 13:21 Message: Logged In: YES user_id=56214 Here's the tz info; I'll email you the 'man tzset' separately. [admin@pilot Python-2.3a1]$ ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3a1]$ env TZ='US/Eastern' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3a1]$ env TZ='Australia/Melbourne' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EST') -36000 -39600 [admin@pilot Python-2.3a1]$ cd ../Python-2.3b1 [admin@pilot Python-2.3b1]$ ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3b1]$ env TZ='US/Eastern' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EDT') 18000 14400 [admin@pilot Python-2.3b1]$ env TZ='Australia/Melbourne' ./python -c 'import time;print time.tzname,time.timezone,time.altzone' ('EST', 'EST') -36000 -39600 [ ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-05-22 00:41 Message: Logged In: YES user_id=46639 This is from my patch. Phillip - can you please upload a copy of 'man tzset' on that Redhat box or email it to zen@shangri-la.dropbear.id.au. I'd also like to see the output of: python -c 'import time;print time.tzname,time.timezone,time.altzone' env TZ='US/Eastern' python -c 'import time;print time.tzname,time.timezone,time.altzone' env TZ='Australia/Melbourne' python -c 'import time;print time.tzname,time.timezone,time.altzone' I'm thinking that tzset(3) and the time libraries are not fully functional on this earlier version of Redhat, possibly by not handling southern hemisphere daylight savings. If so, it needs to be detected during configuration. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 15:00 Message: Logged In: YES user_id=21627 Neal, it appears you have checked in the test for the AEST zone. Can you analyse the test_time failure in more detail? ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2003-05-04 13:19 Message: Logged In: YES user_id=56214 It's an ISP-supplied variant of RedHat 6.2. I see 'libc-2.1.3.so' in the /lib directory, so I assume that's the version. Running 'strings' on it, I find: GNU C Library stable release version 2.1.3, by Roland McGrath et al. Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.19-6.2.16 system on 2002-08-07. Available extensions: GNU libio by Per Bothner The C stubs add-on version 2.1.2. crypt add-on version 2.1 by Michael Glad and others BIND-4.9.7-REL NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Glibc-2.0 compatibility add-on by Cristian Gafton linuxthreads-0.8 by Xavier Leroy libthread_db work sponsored by Alpha Processor Inc Python identifies itself as: Python 2.3b1 (#1, Apr 26 2003, 10:02:40) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 I just tested 2.3a1 andr 2.3a2 to confirm where the errors began. 2.3a1 doesn't show either error. 2.3a2 has the tempfile problem, but not the time problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-05-04 12:42 Message: Logged In: YES user_id=21627 What operating system distribution specifically did you use? What C library does this system use? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728051&group_id=5470 From noreply at sourceforge.net Tue Oct 28 19:47:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 19:47:30 2003 Subject: [Python-bugs-list] [ python-Bugs-827902 ] ctime is not creation time Message-ID: Bugs item #827902, was opened at 2003-10-21 19:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Robert Siemer (siemer) Assigned to: Nobody/Anonymous (nobody) Summary: ctime is not creation time Initial Comment: Hi! http://python.org/doc/current/lib/module-os.path.html says getctime() returns the creation time. But it probably returns the ctime, which has nothing to do with creation. Bye, Robert ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-28 19:47 Message: Logged In: YES user_id=80475 Done. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-28 15:26 Message: Logged In: YES user_id=21627 I suggest to document all of these: it returns the system's ctime, which, on some systems (e.g. Unix) is change time, and, on others (e.g. Windows), is creation time. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-28 01:22 Message: Logged In: YES user_id=80475 Hmm, it looks like there is more that one answer. >From Linux man pages: ctime is the "inode change time" >From MSDN specs: ctime "Indicates the creation time for this storage, stream, or byte array". We can either document both or just put that getctime returns the operating system's ctime field for open storage, a stream, or a byte-array. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-27 18:57 Message: Logged In: YES user_id=21627 So what about the issue that ctime really does mean "creation time" on Windows? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-10-27 15:05 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libposixpath.tex 1.37 and 1.36.12.1. ---------------------------------------------------------------------- Comment By: Johan M. Hahn (johahn) Date: 2003-10-23 03:14 Message: Logged In: YES user_id=887415 On Windows 2000 os.path.ctime (-> ntpath.getctime -> ntpath.stat.st_ctime) returns creation time. ---------------------------------------------------------------------- Comment By: Robert Siemer (siemer) Date: 2003-10-22 17:11 Message: Logged In: YES user_id=150699 ctime is the time of last modification of file status information. Means: gets updated on everything... (-: There is no way on classic Linux-Filesystems to get the creation time. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2003-10-22 16:14 Message: Logged In: YES user_id=43607 ctime is change time. Read the manual (stat(2)): time_t st_atime; /* time of last access */ time_t st_mtime; /* time of last modification */ time_t st_ctime; /* time of last change */ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-22 11:02 Message: Logged In: YES user_id=21627 Why do you say ctime has nothing to do with creation? What else does ctime indicate? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=827902&group_id=5470 From noreply at sourceforge.net Tue Oct 28 20:38:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 20:38:34 2003 Subject: [Python-bugs-list] [ python-Bugs-831574 ] Solaris term.h needs curses.h Message-ID: Bugs item #831574, was opened at 2003-10-28 17:53 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831574&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Martin v. L?wis (loewis) Summary: Solaris term.h needs curses.h Initial Comment: Solaris' term.h requires curses.h to be included first. This causes the configure script to emit lines about a bug in autoconf. From the autoconf mailing lists, their standard response is to fix the configure script, see e.g. http://mail.gnu.org/archive/html/bug-autoconf/2003-05/msg00118.html The following patch against 2.3 branch for configure and configure.in makes things a bit happier. Note that Include/py_curses.h already includes curses.h before term.h, this just fixes the breakage of configure. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-29 12:38 Message: Logged In: YES user_id=29957 Dunno if #ifdef is better or not - I just worked from the example in the attached autoconf mailing list message. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-29 00:08 Message: Logged In: YES user_id=33168 Should the #if be an #ifdef ? Looks fine to me, but I don't know much about autoconf. :-) I think Martin is the expert. Martin do you have an opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831574&group_id=5470 From noreply at sourceforge.net Tue Oct 28 23:27:09 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Tue Oct 28 23:27:15 2003 Subject: [Python-bugs-list] [ python-Bugs-832159 ] C++ extensions using SWIG and MinGW Message-ID: Bugs item #832159, was opened at 2003-10-29 04: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=832159&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Allen Chan (alydar) Assigned to: Nobody/Anonymous (nobody) Summary: C++ extensions using SWIG and MinGW Initial Comment: Using the following three files: -- begin files ----- /* hello.cpp */ #include void hello() { printf("hello world\n"); } ------------------ /* hello.i */ %module hello extern void hello(); ------------------ # setup.py import distutils from distutils.core import setup, Extension setup(name = "Hello World", version = "1.0", ext_modules = [Extension("_hello", ["hello.i","hello.cpp"])]) -- end files ------- executing the command: "python setup.py build_ext -cmingw32 --swig-cpp -f" creates the following output: -- begin output -- running build_ext building '_hello' extension swigging hello.i to hello_wrap.cpp ... [ snipped ] ... cc -mno-cygwin -shared -s build\temp.win32-2.3 \Release\hello_wrap.o build\temp.w in32-2.3\Release\hello.o build\temp.win32-2.3 \Release\_hello.def -LC:\p\Python23 \libs -LC:\p\Python23\PCBuild -lpython23 -o build\lib.win32-2.3\_hello.pyd error: command 'cc' failed: No such file or directory -- end output -- It appears that unixccompiler.py defaults compiler_cxx to use "cc" and then uses it for the linking, and cygwinccompiler.py does not override the compiler_cxx entry. If the self.set_executable() call in the __init__*( function of the Mingw32Compiler class also sets compiler_cxx to use "g++", then the extension build will work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832159&group_id=5470 From noreply at sourceforge.net Wed Oct 29 04:05:21 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 29 04:05:53 2003 Subject: [Python-bugs-list] [ python-Bugs-832236 ] Build fails in ossaudiodev.c with missing macros Message-ID: Bugs item #832236, was opened at 2003-10-29 01: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=832236&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Daniel Parks (danielparks) Assigned to: Nobody/Anonymous (nobody) Summary: Build fails in ossaudiodev.c with missing macros Initial Comment: I'm building Python 2.3.2 with no configure flags on MkLinux Pre-R1. uname -a: Linux gondor.middle.earth 2.0.37-osfmach3 GENERIC_08alpha-20 Fri Jul 30 11:07:38 PDT 1999 ppc unknown The missing macros are: SOUND_MIXER_DIGITAL1, SOUND_MIXER_DIGITAL2, SOUND_MIXER_DIGITAL3, SOUND_MIXER_PHONEIN, SOUND_MIXER_PHONEOUT, SOUND_MIXER_VIDEO, SOUND_MIXER_RADIO, SOUND_MIXER_MONITOR, SNDCTL_DSP_GETODELAY I commented out two lines in setup.py and it seems to have built correctly. I would test it, but I need to go to bed, and I will forget to add this bug tomorrow. I will update this if Python actually works. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832236&group_id=5470 From noreply at sourceforge.net Wed Oct 29 04:39:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 29 04:39:44 2003 Subject: [Python-bugs-list] [ python-Bugs-832251 ] Wrong reference for specific minidom methods Message-ID: Bugs item #832251, was opened at 2003-10-29 10: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=832251&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Francesco Ricciardi (nerby) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong reference for specific minidom methods Initial Comment: In the HTML documentation the method in section 13.7.1 "DOM Objects" of the library reference are listed as HTMLParser method. In the "paper" documentation (PDF-A4 and Ps-A4) the same methods have no module reference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832251&group_id=5470 From noreply at sourceforge.net Wed Oct 29 12:21:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 29 12:21:06 2003 Subject: [Python-bugs-list] [ python-Bugs-832515 ] Bad Security Advice in CGI Documentation Message-ID: Bugs item #832515, was opened at 2003-10-29 11:20 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=832515&group_id=5470 Category: Documentation Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matt Steven (mr_perl) Assigned to: Nobody/Anonymous (nobody) Summary: Bad Security Advice in CGI Documentation Initial Comment: /usr/share/doc/python-docs-2.2.3/html/lib/node305.html Contains the suggestion: "When reading or writing external files, make sure they can be read or written by every user on the system." This is terrible advice, suggesting you make all your files 777. This line should be removed, or replaced with something like "When reading or writing external files, make sure they can be read or written by the web server or appropriate suexec UID" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832515&group_id=5470 From noreply at sourceforge.net Wed Oct 29 12:48:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 29 12:48:29 2003 Subject: [Python-bugs-list] [ python-Bugs-832535 ] Inconsitent line numbering in traceback Message-ID: Bugs item #832535, was opened at 2003-10-29 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=832535&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsitent line numbering in traceback Initial Comment: Transcript below documents the problem. A traceback shows a line with no float() op, but complains of a float op error. I restart the shell, with no changes to the imported module, and this time line 45 is correctly listed. >>> reload(brawley) >>> brawley.test2() elems: 3, 4, 5, 0.5, 'White', sublist: 7,8,9] ['3', ' 4', ' 5', ' 0.5', " 'White'", ' '] ['3', ' 4', ' 5', ' 0.5', " 'White'"] Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 color = elems[-2] ValueError: invalid literal for float(): 'White >>> ================================ RESTART ================================ >>> import brawley >>> brawley.test2() elems: 3, 4, 5, 0.5, 'White', sublist: 7,8,9] ['3', ' 4', ' 5', ' 0.5', " 'White'", ' '] ['3', ' 4', ' 5', ' 0.5', " 'White'"] Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 x,y,z,radius = [float(i) for i in elems[:-3].split(',')] ValueError: invalid literal for float(): 'White ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832535&group_id=5470 From noreply at sourceforge.net Wed Oct 29 12:56:14 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 29 12:56:24 2003 Subject: [Python-bugs-list] [ python-Bugs-832535 ] Inconsitent line numbering in traceback Message-ID: Bugs item #832535, was opened at 2003-10-29 09:48 Message generated for change (Comment added) made by urnerk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832535&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsitent line numbering in traceback Initial Comment: Transcript below documents the problem. A traceback shows a line with no float() op, but complains of a float op error. I restart the shell, with no changes to the imported module, and this time line 45 is correctly listed. >>> reload(brawley) >>> brawley.test2() elems: 3, 4, 5, 0.5, 'White', sublist: 7,8,9] ['3', ' 4', ' 5', ' 0.5', " 'White'", ' '] ['3', ' 4', ' 5', ' 0.5', " 'White'"] Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 color = elems[-2] ValueError: invalid literal for float(): 'White >>> ================================ RESTART ================================ >>> import brawley >>> brawley.test2() elems: 3, 4, 5, 0.5, 'White', sublist: 7,8,9] ['3', ' 4', ' 5', ' 0.5', " 'White'", ' '] ['3', ' 4', ' 5', ' 0.5', " 'White'"] Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 x,y,z,radius = [float(i) for i in elems[:-3].split(',')] ValueError: invalid literal for float(): 'White ---------------------------------------------------------------------- >Comment By: Kirby Urner (urnerk) Date: 2003-10-29 09:56 Message: Logged In: YES user_id=191709 It's a little more serious. After a save/reload, the traceback will echo code that's no longer present in the source at all. Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 x,y,z,radius = [float(i) for i in elems[:-3].split(',')] ValueError: invalid literal for float(): 'White' But line 45 in the saved/reloaded source is really: x,y,z,radius = [float(i) for i in elems.split(',')[:-1]] When I restart the shell and import, the real source code is echoed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832535&group_id=5470 From noreply at sourceforge.net Wed Oct 29 13:02:39 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 29 13:02:46 2003 Subject: [Python-bugs-list] [ python-Bugs-832535 ] Inconsitent line numbering in traceback Message-ID: Bugs item #832535, was opened at 2003-10-29 17:48 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832535&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsitent line numbering in traceback Initial Comment: Transcript below documents the problem. A traceback shows a line with no float() op, but complains of a float op error. I restart the shell, with no changes to the imported module, and this time line 45 is correctly listed. >>> reload(brawley) >>> brawley.test2() elems: 3, 4, 5, 0.5, 'White', sublist: 7,8,9] ['3', ' 4', ' 5', ' 0.5', " 'White'", ' '] ['3', ' 4', ' 5', ' 0.5', " 'White'"] Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 color = elems[-2] ValueError: invalid literal for float(): 'White >>> ================================ RESTART ================================ >>> import brawley >>> brawley.test2() elems: 3, 4, 5, 0.5, 'White', sublist: 7,8,9] ['3', ' 4', ' 5', ' 0.5', " 'White'", ' '] ['3', ' 4', ' 5', ' 0.5', " 'White'"] Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 x,y,z,radius = [float(i) for i in elems[:-3].split(',')] ValueError: invalid literal for float(): 'White ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-10-29 18:02 Message: Logged In: YES user_id=6656 Is this the hoary old "being lied to by linecache" thing? I complain about that every now and again, but haven't actually done anything about it yet... ---------------------------------------------------------------------- Comment By: Kirby Urner (urnerk) Date: 2003-10-29 17:56 Message: Logged In: YES user_id=191709 It's a little more serious. After a save/reload, the traceback will echo code that's no longer present in the source at all. Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 x,y,z,radius = [float(i) for i in elems[:-3].split(',')] ValueError: invalid literal for float(): 'White' But line 45 in the saved/reloaded source is really: x,y,z,radius = [float(i) for i in elems.split(',')[:-1]] When I restart the shell and import, the real source code is echoed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832535&group_id=5470 From noreply at sourceforge.net Wed Oct 29 18:10:22 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 29 18:10:54 2003 Subject: [Python-bugs-list] [ python-Feature Requests-759792 ] Make urllib2 more extensible (patch) Message-ID: Feature Requests item #759792, was opened at 2003-06-24 14:16 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Make urllib2 more extensible (patch) Initial Comment: Problem with urllib2 as it stands: many things would be nice to implement as a handler rather than by overriding methods (and inevitably duplicating code and increasing fragility), but it's not always possible to do so. For example (all from HTTP), automatically adding Referer headers, handling 200 responses that should have been non-2xx errors if the server were sane, handling cookies, handling HTTP-EQUIV headers as if they were normal HTTP headers, automatically making responses seekable, and following Refresh headers. I've done all these things, but I had to duplicate code to do it, because I don't see how to do it with handlers. I've now rewritten this code by adding a 'processor' scheme to urllib2 (I'm *not* using 'scheme' in the technical URL sense here!). Processors work quite similarly to handlers, except that 1. They always *all* get run (rather than just the first to handle a request or response -- unlike handlers). 2. The methods that get called on processors are of the form _request and _response, and are called, respectively, immediately before and immediately after the normal OpenerDirector.open machinery. http_request, for example, gets called on all processors before, and pre-processes HTTP requests; http_response post-processes HTTP responses. 3. _request methods return request objects, and _response methods return response objects. 4. Even 200 responses get processed. You use it like this: # just pass processors to build_opener as if they were handlers opener = build_opener(FooHandler, BarProcessor, BazHandler) response = opener.open("http://www.example.com/") I've reimplemented all my stuff (the features listed in the first paragraph, above) in terms of this scheme, and it all seems to be working fine (but no unit tests yet). So, the scheme does achieve the extensibility it aims for. The patch I've attached here doesn't include most of those features -- the only new functionality it adds is an HTTPRefererProcessor. If this gets accepted, I intend to submit patches adding new processors for cookie handling etc. later. Two things I'd like to know: 1. will my solution break people's code 2. is there a better way? For 1., I *think* it shouldn't break code. For 2., the obvious problem with my solution (below) is that handlers are pretty similar to my processors already. The thing is, I can't see how to reimplement these things in terms of handlers. First, I need to *see* all requests (responses) -- I can do that using handlers by giving them low (high) .handler_order in Python 2.3 and returning None from http_open (http_error_xxx). However, 200 responses never get seen by http_error_xxx, so that doesn't work (and changing that would break old code). Second, I need to actually modify the requests and responses. Sometimes I'd much rather do that by making a new request or response than modifying the old one in-place (redirections, for example) -- and in general, even if I *am* just modifying in-place, I'd still prefer to explictly return the object than rely on side-effects. Perhaps just adding a couple of hooks to AbstractHTTPHandler might get these jobs done, but I think the increased simplicity of AbstractHTTPHandler.do_open and the various processors makes my approach worthwhile (assuming it actually works & is backwards-compat., of course...). Comments? A few notes: Some headers (Content-Length, Referer, ...) mustn't be copied to requests for a redirected URL. This requires the addition of a new dict to Request. I've added an add_unredirected_headers method, too. The old implementation just sends these headers directly, but that's not possible if you want to use procesors to implement these things. The current response object (httplib.HTTPResponse, wrapped with urllib.addinfourl) doesn't include response code or message (because code is always 200). The patch just assigns .code and .msg attributes (maybe they should be methods, for uniformity with the rest of the response interface). Backwards-compatibility notes: People who override AbstractHTTPHandler.do_open will do non-200 response handling there, which will break processors, but that's a forwards-compat. issue. I don't think the existence of overridden do_open methods in old code should be a problem for backwards-compatibility. Note that, though processors see all responses, the end user still only gets 200 responses returned. ErrorProcessor ensures that by passing non-200 responses on to the existing urllib2 error machinery. John ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-10-29 23:10 Message: Logged In: YES user_id=261020 Just to note a minor change that should happen if this gets accepted: processors shouldn't be separate objects, but rather just a new interface that handler objects can support. That way, a single object can implement both interfaces. This makes implementing response cache handlers easier, for example. Not uploading a new patch, since it's a trivial code change. It might also be useful to have default_request and default_response methods (by analogy with default_open), for example for any response caching that's independent of protocol scheme. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-08-12 16:19 Message: Logged In: YES user_id=31392 Dont't wait more than a couple of weeks for me. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-12 12:58 Message: Logged In: YES user_id=261020 If anybody wants to see some concrete examples of use of this patch, ask me & I'll mail them to you (actually, they use my urllib2 extension module rather than the patch, but the differences are trivial). BTW Jeremy, any guess about when in your Copious Free Time you're likely to get to this? I'm wondering whether to just release my code as-is, or wait for your comments. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-08-12 12:39 Message: Logged In: YES user_id=261020 Possibly similar to Apache filters, but sio's filters seem to be for filtering stream data rather than request / response objects -- has no concept of headers, for example. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-12 06:46 Message: Logged In: YES user_id=357491 Sounds kind of like Apache's filters. The idea seems fine, but perhaps this could instead be worked in with Guido's sio package in the CVS sandbox? Seems to be a similar idea. Perhaps there could some way of hooking that code into urllib2? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-31 23:15 Message: Logged In: YES user_id=31392 In principle, I'm in favor of this. I'd like to take some time to review the design and code. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-08 16:13 Message: Logged In: YES user_id=261020 I just noticed the patch breaks on https. Trivially fixed by adding lines like https_request = http_request to the various processor classes. Also, another use case: gzip Content-encoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=759792&group_id=5470 From noreply at sourceforge.net Wed Oct 29 18:27:05 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 29 18:27:10 2003 Subject: [Python-bugs-list] [ python-Bugs-626543 ] urllib2 doesn't do HTTP-EQUIV & Refresh Message-ID: Bugs item #626543, was opened at 2002-10-21 21:57 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626543&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't do HTTP-EQUIV & Refresh Initial Comment: I just added support for HTML's META HTTP-EQUIV and zero-time Refresh HTTP headers to my 'ClientCookie' package (which exports essentially a clone of the urllib2 interface that knows about cookies, making use of urllib2 in the implementation). I didn't make a patch for urllib2 itself but it would be easy to do so. I don't plan to do this immediately, but will eventually (assuming Jeremy thinks it's advisible) -- I just wanted to register this fact to prevent duplication of effort. [BTW, this version of ClientCookie isn't on my web page yet -- my motherboard just died.] I'm sure you know this already, but: HTTP-EQUIV is just a way of putting headers in the HEAD section of an HTML document; Refresh is a Netscape 1.1 header that indicates that a browser should redirect after a specified time. Refresh headers with zero time act like redirections. The net result of the code I just wrote is that if you urlopen a URL that points to an HTML document like this: you're automatically redirected to "http://acme.com/new_url.htm". Same thing happens if the Refresh is in the HTTP headers, because all the HTTP-EQUIV headers are treated like real HTTP headers. Refresh with non-zero delay time is ignored (the urlopen returns the document body unchanged and does not redirect, but does still add the Refresh header to the HTTP headers). A few issues: 0) AFAIK, the Refresh header is not specified in any RFC, but only here: http://wp.netscape.com/assist/net_sites/pushpull.html (HTTP-EQUIV seems to be in the HTML 4.0 standard, maybe earlier ones too) 1) Infinite loops should be detected, as for HTTP 30x? Presumably yes. 2) Should add HTTP-EQUIV headers to response object, or just treat them like headers internally? Perhaps it should be possible to get both behaviours? 3) Bug in my implementation: is greedy with reading body data from httplib's file object. John ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-10-29 23:27 Message: Logged In: YES user_id=261020 Just an update: - this could now be implemented as a handler (and already is, in my ClientCookie package) using RFE 759792, rather than having to be mixed in with HTTPHandler - the issues I listed in my initial comment, and the backwards-compatibility issue raised by MvL are now resolved - it needs reimplementing using HTMLParser (currently uses htmllib) if it's to go in the standard library; I plan to do this in time for 2.4 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-26 14:30 Message: Logged In: YES user_id=21627 I would try to subclass HTTPHandler, and then provide a build_opener wrapper that installs this handler instead of the normal http handler (the latter is optional, since the user could just do build_opener(HTTPRefreshHandler)). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-24 00:20 Message: Logged In: YES user_id=261020 What do you think the solution to the backwards- compatibility problem is? Leave urllib2 as-is? Add a switch to turn it on? Something else? At the moment, I just deal with it in AbstractHTTPHandler. It would be nice to treat it like the other redirections, by writing a RefreshHandler -- this would solve the backwards- compatibility issue. However, OpenerDirector.error always calls http_error_xxx ATM (where xxx is the HTTP error code), so without changing that, I don't think a RefreshHandler is really possible. I suppose the sensible solution is just to make a new HTTPHandler and HTTPSHandler? Can you think of any way in which supporting HTTP-EQUIV would mess up backwards compatibility, assuming the body is unchanged but the headers do have the HTTP-EQUIV headers added? John ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2002-10-23 14:54 Message: Logged In: YES user_id=21627 In addition to the issues you have mentioned, there is also the backwards compatibility issue: Some applications might expect to get a meta-refresh document from urllib, then parse it and retry themselves. Those applications would break with such a change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=626543&group_id=5470 From noreply at sourceforge.net Wed Oct 29 18:56:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 29 18:56:54 2003 Subject: [Python-bugs-list] [ python-Bugs-820583 ] urllib2 silently returns None when auth_uri is mismatched Message-ID: Bugs item #820583, was opened at 2003-10-09 13:11 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820583&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christopher Armstrong (radeex) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 silently returns None when auth_uri is mismatched Initial Comment: Code like the following, where the `uri' argument which I pass to add_password is not actually the URI that the web server gives me in its request for basic auth, makes the return value of OpenDirector.open None. This is either a code bug or a documentation bug. I expected director.open to raise an error, but saying something like "open will return None in these cases: ...." would also be a valid solution, if one that's not as good, IMO... the AuthHandler could raise an error once it realizes that none of the URIs we have match, perhaps? import urllib2 realm = "Linksys BEFW11S4 V4" passman = urllib2.HTTPPasswordMgr() passman.add_password(realm, 'NOT_WHAT_THE_SERVER_GIVES_ME', 'user', 'password') auther = urllib2.HTTPBasicAuthHandler(passman) getter = urllib2.HTTPHandler() director = urllib2.OpenerDirector() director.add_handler(auther) director.add_handler(getter) f = director.open('http://192.168.1.1/Status.htm') print f, "is None" ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-10-29 23:56 Message: Logged In: YES user_id=261020 It's a doc bug. I'll add a doc patch later. Returning None from a handler means "I can't handle this, but another handler might". So AuthHandler is correct to return None, and shouldn't raise an exception. If you want to get a URLError in cases where all relevant handlers return None, you need to do: director.add_handler(UnknownHandler) (which build_opener will do for you, actually) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=820583&group_id=5470 From noreply at sourceforge.net Wed Oct 29 20:36:23 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Wed Oct 29 20:36:27 2003 Subject: [Python-bugs-list] [ python-Bugs-832799 ] Please link modules with shared lib Message-ID: Bugs item #832799, was opened at 2003-10-29 20: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=832799&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: Please link modules with shared lib Initial Comment: We've been working with libraries that are loaded with dlopen (on Linux and Solaris, the land of ELF) and which, in turn, use the embedded python interpreter. Due to the behavior of the dynamic linker, this would work much better if modules were, by default, linked with -lpython2.3 instead of just left with hanging undefined symbols. Here's why. The main executable isn't linked with python, and none of it's direct dependents are. So, the python symbols aren't in the global namespace. The dlopened library is linked with python. However, when the dlopened library dlopens the modules, the linux linker is not clever enough to allow the second- order library to use symbols from its parent. (Solaris has such a feature, but not linux). So, one has to manually dlopen the python library with RTLD_GLOBAL to make it work. If each module had a NEED for the python lib (via -l at linktime), all this would just work. I've got some local patches to build_ext.py for this purpose, but it would be nice to have official support. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 From noreply at sourceforge.net Thu Oct 30 05:05:42 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 05:05:48 2003 Subject: [Python-bugs-list] [ python-Bugs-832946 ] re.finditer() hangs with some re involving \[ Message-ID: Bugs item #832946, was opened at 2003-10-30 10: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=832946&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Angel Perea Martinez (angelpeream) Assigned to: Fredrik Lundh (effbot) Summary: re.finditer() hangs with some re involving \[ Initial Comment: When called with some parameters (see test below), re.finditer() enters an infinite loop. Note that as far as I know, this is not bug 817234. In this case, finditer() does NOT return anything: symply hangs. I work in a W2000 environment, with a fresh-installed python v2.3.2 . That is: sys.version_info() = (2, 3, 2, 'final', 0) To reproduce it: --------------- import re pattern = re.compile(r"\[([^][]+)+\]") text = "[ xxxxx , xxxxxx , xxxxxx" for n in re.finditer(pattern, text): print "this string will not appear" print n.group(0) ---------- I could'nt further simplify the pattern, neither the text. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832946&group_id=5470 From noreply at sourceforge.net Thu Oct 30 10:08:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 10:12:24 2003 Subject: [Python-bugs-list] [ python-Bugs-833106 ] Match delimited by ^ and $ doesn't catch everything Message-ID: Bugs item #833106, was opened at 2003-10-30 15: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=833106&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Kochanski (gpk) Assigned to: Fredrik Lundh (effbot) Summary: Match delimited by ^ and $ doesn't catch everything Initial Comment: import re _sfp = re.compile(r'^(?:(.*?)([XY][0-9]))*(.*?)$') print _sfp.search('testX1Y2').groups() print _sfp.match('testX1Y2').groups() print _sfp.search('testY1X2again').groups() print _sfp.search('testX1').groups() print _sfp.search('Y2').groups() Yields ('', 'Y2', '') ('', 'Y2', '') ('', 'X2', 'again') ('test', 'X1', '') ('', 'Y2', '') Note that in the first three outputs, the string 'test' doesn't appear in any group. Note also that 'X1' doesn't appear in any group in the first two outputs. The RE is delimited by ^ and $, so it should match everything or fail. It doesn't fail. All the elements of the RE are in parentheses, so everything should fall into one group or another. Thus, all the text should show up in one group or another. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833106&group_id=5470 From noreply at sourceforge.net Thu Oct 30 10:31:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 10:31:55 2003 Subject: [Python-bugs-list] [ python-Bugs-833106 ] Match delimited by ^ and $ doesn't catch everything Message-ID: Bugs item #833106, was opened at 2003-10-30 15:08 Message generated for change (Comment added) made by gpk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833106&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Kochanski (gpk) Assigned to: Fredrik Lundh (effbot) Summary: Match delimited by ^ and $ doesn't catch everything Initial Comment: import re _sfp = re.compile(r'^(?:(.*?)([XY][0-9]))*(.*?)$') print _sfp.search('testX1Y2').groups() print _sfp.match('testX1Y2').groups() print _sfp.search('testY1X2again').groups() print _sfp.search('testX1').groups() print _sfp.search('Y2').groups() Yields ('', 'Y2', '') ('', 'Y2', '') ('', 'X2', 'again') ('test', 'X1', '') ('', 'Y2', '') Note that in the first three outputs, the string 'test' doesn't appear in any group. Note also that 'X1' doesn't appear in any group in the first two outputs. The RE is delimited by ^ and $, so it should match everything or fail. It doesn't fail. All the elements of the RE are in parentheses, so everything should fall into one group or another. Thus, all the text should show up in one group or another. ---------------------------------------------------------------------- >Comment By: Greg Kochanski (gpk) Date: 2003-10-30 15:31 Message: Logged In: YES user_id=6290 Here's another example: import re _sfp = re.compile(r'([][][0-9])|(.*?)') print _sfp.findall('testX1Y2') print _sfp.findall('testY1X2again') print _sfp.findall('testX1') print _sfp.findall('Y2') yields: [('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', '')] [('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', '')] [('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', '')] [('', ''), ('', ''), ('', '')] Which is weird in many dimensions. First of all, the RE I specified could be interpreted to match an infinite number of times. After all, it contains a (.*?) element, which should be happiest with a zero-length match, so one can stack up an infinite number of zero-length matches in any finite string. So, why is it finite? Probably it should throw some kind of exception in the compile phase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833106&group_id=5470 From noreply at sourceforge.net Thu Oct 30 10:36:48 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 10:36:54 2003 Subject: [Python-bugs-list] [ python-Bugs-833106 ] Match delimited by ^ and $ doesn't catch everything Message-ID: Bugs item #833106, was opened at 2003-10-30 10: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=833106&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Kochanski (gpk) >Assigned to: Nobody/Anonymous (nobody) Summary: Match delimited by ^ and $ doesn't catch everything Initial Comment: import re _sfp = re.compile(r'^(?:(.*?)([XY][0-9]))*(.*?)$') print _sfp.search('testX1Y2').groups() print _sfp.match('testX1Y2').groups() print _sfp.search('testY1X2again').groups() print _sfp.search('testX1').groups() print _sfp.search('Y2').groups() Yields ('', 'Y2', '') ('', 'Y2', '') ('', 'X2', 'again') ('test', 'X1', '') ('', 'Y2', '') Note that in the first three outputs, the string 'test' doesn't appear in any group. Note also that 'X1' doesn't appear in any group in the first two outputs. The RE is delimited by ^ and $, so it should match everything or fail. It doesn't fail. All the elements of the RE are in parentheses, so everything should fall into one group or another. Thus, all the text should show up in one group or another. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-10-30 10:36 Message: Logged In: YES user_id=31435 These results look correct to me. When a capturing group matches more than once in the course of a match, only the last substring it matched is captured. Start by understanding a simpler regexp: >>> import re >>> p = re.compile(r"^(a)+$") >>> m = p.search("aaaaa") >>> m.group(1) 'a' >>> m.span(1) (4, 5) >>> # so group 1 last matched "aaaaa"[4:5], the last 'a' # in the string When you understand that, the behavior of your more- complicated regexp should become clear. In exactly analogous fashion, your groups capture the last substrings they matched: >>> m = _sfp.search('testX1Y2') >>> m.span(1) # last matched empty string between 1 and Y (6, 6) >>> m.span(2) # last matched Y2 (6, 8) >>> m.span(3) # last matched empty string at end of string (8, 8) >>> ---------------------------------------------------------------------- Comment By: Greg Kochanski (gpk) Date: 2003-10-30 10:31 Message: Logged In: YES user_id=6290 Here's another example: import re _sfp = re.compile(r'([][][0-9])|(.*?)') print _sfp.findall('testX1Y2') print _sfp.findall('testY1X2again') print _sfp.findall('testX1') print _sfp.findall('Y2') yields: [('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', '')] [('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', '')] [('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', '')] [('', ''), ('', ''), ('', '')] Which is weird in many dimensions. First of all, the RE I specified could be interpreted to match an infinite number of times. After all, it contains a (.*?) element, which should be happiest with a zero-length match, so one can stack up an infinite number of zero-length matches in any finite string. So, why is it finite? Probably it should throw some kind of exception in the compile phase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833106&group_id=5470 From noreply at sourceforge.net Thu Oct 30 10:41:50 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 10:41:54 2003 Subject: [Python-bugs-list] [ python-Bugs-833137 ] re.matchobject.findall() adds an extra element Message-ID: Bugs item #833137, was opened at 2003-10-30 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=833137&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Kochanski (gpk) Assigned to: Fredrik Lundh (effbot) Summary: re.matchobject.findall() adds an extra element Initial Comment: import re _sfp = re.compile(r'([][][0-9])|([^][]*)') print _sfp.findall('test[1]2') print _sfp.findall('test]1[2again') print _sfp.findall('test[1') print _sfp.findall(']2') Yields: [('', 'test'), ('[1', ''), (']2', ''), ('', '')] [('', 'test'), (']1', ''), ('[2', ''), ('', 'again'), ('', '')] [('', 'test'), ('[1', ''), ('', '')] [(']2', ''), ('', '')] Where do those empty matches at the end come from? Admittedly the [^][]* pattern can match a zero length string, but if it's going to match a zero-length string at the end, why doesn't it also match at the beginning? Or in between every nonzero match? One would think, in the interests of economy and sanity, that zero length matches should be avoided unless they are needed to use up all of the input string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833137&group_id=5470 From noreply at sourceforge.net Thu Oct 30 10:55:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 10:55:06 2003 Subject: [Python-bugs-list] [ python-Bugs-833137 ] re.matchobject.findall() adds an extra element Message-ID: Bugs item #833137, was opened at 2003-10-30 16:41 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833137&group_id=5470 Category: Regular Expressions Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Greg Kochanski (gpk) Assigned to: Fredrik Lundh (effbot) Summary: re.matchobject.findall() adds an extra element Initial Comment: import re _sfp = re.compile(r'([][][0-9])|([^][]*)') print _sfp.findall('test[1]2') print _sfp.findall('test]1[2again') print _sfp.findall('test[1') print _sfp.findall(']2') Yields: [('', 'test'), ('[1', ''), (']2', ''), ('', '')] [('', 'test'), (']1', ''), ('[2', ''), ('', 'again'), ('', '')] [('', 'test'), ('[1', ''), ('', '')] [(']2', ''), ('', '')] Where do those empty matches at the end come from? Admittedly the [^][]* pattern can match a zero length string, but if it's going to match a zero-length string at the end, why doesn't it also match at the beginning? Or in between every nonzero match? One would think, in the interests of economy and sanity, that zero length matches should be avoided unless they are needed to use up all of the input string. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2003-10-30 16:55 Message: Logged In: YES user_id=38376 a|b always checks pattern a before it checks pattern b, and findall returns all non-overlapping matches it can find. See the library reference for more information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833137&group_id=5470 From noreply at sourceforge.net Thu Oct 30 11:08:18 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 11:08:23 2003 Subject: [Python-bugs-list] [ python-Bugs-832946 ] re.finditer() hangs with some re involving \[ Message-ID: Bugs item #832946, was opened at 2003-10-30 11:05 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832946&group_id=5470 Category: Regular Expressions Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Angel Perea Martinez (angelpeream) Assigned to: Fredrik Lundh (effbot) Summary: re.finditer() hangs with some re involving \[ Initial Comment: When called with some parameters (see test below), re.finditer() enters an infinite loop. Note that as far as I know, this is not bug 817234. In this case, finditer() does NOT return anything: symply hangs. I work in a W2000 environment, with a fresh-installed python v2.3.2 . That is: sys.version_info() = (2, 3, 2, 'final', 0) To reproduce it: --------------- import re pattern = re.compile(r"\[([^][]+)+\]") text = "[ xxxxx , xxxxxx , xxxxxx" for n in re.finditer(pattern, text): print "this string will not appear" print n.group(0) ---------- I could'nt further simplify the pattern, neither the text. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2003-10-30 17:08 Message: Logged In: YES user_id=38376 You're using an RE with nested repeat operators (+). This forces the engine to check all all possible combinations of of the inner and outer repeat before it can be sure that no possible combination results in a match. To see this in action, run this script: import re, time pattern = re.compile(r"\[([^][]+)+\]") text = "[ xxxxx , xxxxxx , xxxxxx" for i in range(len(text)): t0 = time.time() print i, re.findall(pattern, text[:i]), print time.time() - t0 on a relatively slow PC, this prints 0 [] 0.0 1 [] 0.0 2 [] 0.0 3 [] 0.0 4 [] 0.0 5 [] 0.0 6 [] 0.0 7 [] 0.00999999046326 8 [] 0.0 9 [] 0.0 10 [] 0.0 11 [] 0.00999999046326 12 [] 0.0 13 [] 0.00999999046326 14 [] 0.0199999809265 15 [] 0.0400000810623 16 [] 0.0899999141693 17 [] 0.151000022888 18 [] 0.299999952316 19 [] 0.651000022888 20 [] 1.22200000286 21 [] 2.51300001144 22 [] 5.10800004005 23 [] 11.8769999743 24 [] 21.9309999943 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832946&group_id=5470 From noreply at sourceforge.net Thu Oct 30 11:26:02 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 11:26:09 2003 Subject: [Python-bugs-list] [ python-Bugs-833106 ] Match delimited by ^ and $ doesn't catch everything Message-ID: Bugs item #833106, was opened at 2003-10-30 16:08 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833106&group_id=5470 Category: Regular Expressions Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Greg Kochanski (gpk) >Assigned to: Fredrik Lundh (effbot) Summary: Match delimited by ^ and $ doesn't catch everything Initial Comment: import re _sfp = re.compile(r'^(?:(.*?)([XY][0-9]))*(.*?)$') print _sfp.search('testX1Y2').groups() print _sfp.match('testX1Y2').groups() print _sfp.search('testY1X2again').groups() print _sfp.search('testX1').groups() print _sfp.search('Y2').groups() Yields ('', 'Y2', '') ('', 'Y2', '') ('', 'X2', 'again') ('test', 'X1', '') ('', 'Y2', '') Note that in the first three outputs, the string 'test' doesn't appear in any group. Note also that 'X1' doesn't appear in any group in the first two outputs. The RE is delimited by ^ and $, so it should match everything or fail. It doesn't fail. All the elements of the RE are in parentheses, so everything should fall into one group or another. Thus, all the text should show up in one group or another. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2003-10-30 17:26 Message: Logged In: YES user_id=38376 In the first example, the middle group matches everything, but only the last match is captured (see tim's reply). In the second example, findall returns all non-overlapping matches, but empty matches are only included once (that is, the engine moves at least one character for each match). This is documented behaviour. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-10-30 16:36 Message: Logged In: YES user_id=31435 These results look correct to me. When a capturing group matches more than once in the course of a match, only the last substring it matched is captured. Start by understanding a simpler regexp: >>> import re >>> p = re.compile(r"^(a)+$") >>> m = p.search("aaaaa") >>> m.group(1) 'a' >>> m.span(1) (4, 5) >>> # so group 1 last matched "aaaaa"[4:5], the last 'a' # in the string When you understand that, the behavior of your more- complicated regexp should become clear. In exactly analogous fashion, your groups capture the last substrings they matched: >>> m = _sfp.search('testX1Y2') >>> m.span(1) # last matched empty string between 1 and Y (6, 6) >>> m.span(2) # last matched Y2 (6, 8) >>> m.span(3) # last matched empty string at end of string (8, 8) >>> ---------------------------------------------------------------------- Comment By: Greg Kochanski (gpk) Date: 2003-10-30 16:31 Message: Logged In: YES user_id=6290 Here's another example: import re _sfp = re.compile(r'([][][0-9])|(.*?)') print _sfp.findall('testX1Y2') print _sfp.findall('testY1X2again') print _sfp.findall('testX1') print _sfp.findall('Y2') yields: [('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', '')] [('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', '')] [('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', ''), ('', '')] [('', ''), ('', ''), ('', '')] Which is weird in many dimensions. First of all, the RE I specified could be interpreted to match an infinite number of times. After all, it contains a (.*?) element, which should be happiest with a zero-length match, so one can stack up an infinite number of zero-length matches in any finite string. So, why is it finite? Probably it should throw some kind of exception in the compile phase. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833106&group_id=5470 From noreply at sourceforge.net Thu Oct 30 11:28:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 11:28:39 2003 Subject: [Python-bugs-list] [ python-Bugs-832946 ] re.finditer() hangs with some re involving \[ Message-ID: Bugs item #832946, was opened at 2003-10-30 05:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832946&group_id=5470 Category: Regular Expressions Group: Python 2.3 >Status: Open >Resolution: None Priority: 5 Submitted By: Angel Perea Martinez (angelpeream) Assigned to: Fredrik Lundh (effbot) Summary: re.finditer() hangs with some re involving \[ Initial Comment: When called with some parameters (see test below), re.finditer() enters an infinite loop. Note that as far as I know, this is not bug 817234. In this case, finditer() does NOT return anything: symply hangs. I work in a W2000 environment, with a fresh-installed python v2.3.2 . That is: sys.version_info() = (2, 3, 2, 'final', 0) To reproduce it: --------------- import re pattern = re.compile(r"\[([^][]+)+\]") text = "[ xxxxx , xxxxxx , xxxxxx" for n in re.finditer(pattern, text): print "this string will not appear" print n.group(0) ---------- I could'nt further simplify the pattern, neither the text. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-30 11:28 Message: Logged In: YES user_id=33168 Are you sure it's an infinite loop? It takes a while to complete on my 4 year old box (Linux), but it does complete. How long did you let this run? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-10-30 11:08 Message: Logged In: YES user_id=38376 You're using an RE with nested repeat operators (+). This forces the engine to check all all possible combinations of of the inner and outer repeat before it can be sure that no possible combination results in a match. To see this in action, run this script: import re, time pattern = re.compile(r"\[([^][]+)+\]") text = "[ xxxxx , xxxxxx , xxxxxx" for i in range(len(text)): t0 = time.time() print i, re.findall(pattern, text[:i]), print time.time() - t0 on a relatively slow PC, this prints 0 [] 0.0 1 [] 0.0 2 [] 0.0 3 [] 0.0 4 [] 0.0 5 [] 0.0 6 [] 0.0 7 [] 0.00999999046326 8 [] 0.0 9 [] 0.0 10 [] 0.0 11 [] 0.00999999046326 12 [] 0.0 13 [] 0.00999999046326 14 [] 0.0199999809265 15 [] 0.0400000810623 16 [] 0.0899999141693 17 [] 0.151000022888 18 [] 0.299999952316 19 [] 0.651000022888 20 [] 1.22200000286 21 [] 2.51300001144 22 [] 5.10800004005 23 [] 11.8769999743 24 [] 21.9309999943 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832946&group_id=5470 From noreply at sourceforge.net Thu Oct 30 11:30:52 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 11:30:57 2003 Subject: [Python-bugs-list] [ python-Bugs-832946 ] re.finditer() hangs with some re involving \[ Message-ID: Bugs item #832946, was opened at 2003-10-30 05:05 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832946&group_id=5470 Category: Regular Expressions Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Angel Perea Martinez (angelpeream) Assigned to: Fredrik Lundh (effbot) Summary: re.finditer() hangs with some re involving \[ Initial Comment: When called with some parameters (see test below), re.finditer() enters an infinite loop. Note that as far as I know, this is not bug 817234. In this case, finditer() does NOT return anything: symply hangs. I work in a W2000 environment, with a fresh-installed python v2.3.2 . That is: sys.version_info() = (2, 3, 2, 'final', 0) To reproduce it: --------------- import re pattern = re.compile(r"\[([^][]+)+\]") text = "[ xxxxx , xxxxxx , xxxxxx" for n in re.finditer(pattern, text): print "this string will not appear" print n.group(0) ---------- I could'nt further simplify the pattern, neither the text. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-30 11:28 Message: Logged In: YES user_id=33168 Are you sure it's an infinite loop? It takes a while to complete on my 4 year old box (Linux), but it does complete. How long did you let this run? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-10-30 11:08 Message: Logged In: YES user_id=38376 You're using an RE with nested repeat operators (+). This forces the engine to check all all possible combinations of of the inner and outer repeat before it can be sure that no possible combination results in a match. To see this in action, run this script: import re, time pattern = re.compile(r"\[([^][]+)+\]") text = "[ xxxxx , xxxxxx , xxxxxx" for i in range(len(text)): t0 = time.time() print i, re.findall(pattern, text[:i]), print time.time() - t0 on a relatively slow PC, this prints 0 [] 0.0 1 [] 0.0 2 [] 0.0 3 [] 0.0 4 [] 0.0 5 [] 0.0 6 [] 0.0 7 [] 0.00999999046326 8 [] 0.0 9 [] 0.0 10 [] 0.0 11 [] 0.00999999046326 12 [] 0.0 13 [] 0.00999999046326 14 [] 0.0199999809265 15 [] 0.0400000810623 16 [] 0.0899999141693 17 [] 0.151000022888 18 [] 0.299999952316 19 [] 0.651000022888 20 [] 1.22200000286 21 [] 2.51300001144 22 [] 5.10800004005 23 [] 11.8769999743 24 [] 21.9309999943 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832946&group_id=5470 From noreply at sourceforge.net Thu Oct 30 13:57:15 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 13:57:26 2003 Subject: [Python-bugs-list] [ python-Bugs-487471 ] urllib2 proxyhandle won't work. Message-ID: Bugs item #487471, was opened at 2001-11-30 04:54 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ha Shao (hashao) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 proxyhandle won't work. Initial Comment: For python 2.2b2: Adding proxyhandler with build_opener, install_opener does not work since order of the handlers does matter (my guess). In the current code, new handlers are appended at the end of the handlers list. At least under windows, the proxyhandle will never got called if it is added with install_opener. HTTPHandler always get called before proxyhandler if the default list is altered. The attached patch try to reserve the order of handlers based on their baseclass when adding new handlers. Handlers with the same baseclasses might be added more than once. Not sure if it is a good thing or bad thing. Current code will raise except when it trys to remove the default handlers twice. Since order does matter, build_opener should be repleased by a list like class such that user can insert their handlers to specific place. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-10-30 10:57 Message: Logged In: NO This should be closed. I don't recall which minor version of 2.2 this was introduced at, but there's no need to replace build_opener any more. The most you have to do is to explicitly pass a handler or two to build_opener with appropriately set handler_order attributes. Or you can subclass the handlers. ---------------------------------------------------------------------- Comment By: Micah Stetson (micahs) Date: 2003-05-07 16:29 Message: Logged In: YES user_id=774014 I don't know about Ha Shao, but I have the problem with Python 2.2.2. My work around was to modify urllib2.build_opener to add the user's supplied handlers before the defaults. Shao's idea of a list-like class is probably better. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 13:50 Message: Logged In: YES user_id=33168 Ha Shao, I know there were many changes in Python 2.2.x in this area. Do you still have this problem? Can this bug be closed? ---------------------------------------------------------------------- Comment By: Ha Shao (hashao) Date: 2001-11-30 05:10 Message: Logged In: YES user_id=8717 forgot some code and changed a stupid variable name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 From noreply at sourceforge.net Thu Oct 30 14:02:58 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 14:03:04 2003 Subject: [Python-bugs-list] [ python-Bugs-487471 ] urllib2 proxyhandle won't work. Message-ID: Bugs item #487471, was opened at 2001-11-30 12:54 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Ha Shao (hashao) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 proxyhandle won't work. Initial Comment: For python 2.2b2: Adding proxyhandler with build_opener, install_opener does not work since order of the handlers does matter (my guess). In the current code, new handlers are appended at the end of the handlers list. At least under windows, the proxyhandle will never got called if it is added with install_opener. HTTPHandler always get called before proxyhandler if the default list is altered. The attached patch try to reserve the order of handlers based on their baseclass when adding new handlers. Handlers with the same baseclasses might be added more than once. Not sure if it is a good thing or bad thing. Current code will raise except when it trys to remove the default handlers twice. Since order does matter, build_opener should be repleased by a list like class such that user can insert their handlers to specific place. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-10-30 19:02 Message: Logged In: YES user_id=261020 That last comment was from me (cookie problems, ironically). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-10-30 18:57 Message: Logged In: NO This should be closed. I don't recall which minor version of 2.2 this was introduced at, but there's no need to replace build_opener any more. The most you have to do is to explicitly pass a handler or two to build_opener with appropriately set handler_order attributes. Or you can subclass the handlers. ---------------------------------------------------------------------- Comment By: Micah Stetson (micahs) Date: 2003-05-08 00:29 Message: Logged In: YES user_id=774014 I don't know about Ha Shao, but I have the problem with Python 2.2.2. My work around was to modify urllib2.build_opener to add the user's supplied handlers before the defaults. Shao's idea of a list-like class is probably better. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-13 21:50 Message: Logged In: YES user_id=33168 Ha Shao, I know there were many changes in Python 2.2.x in this area. Do you still have this problem? Can this bug be closed? ---------------------------------------------------------------------- Comment By: Ha Shao (hashao) Date: 2001-11-30 13:10 Message: Logged In: YES user_id=8717 forgot some code and changed a stupid variable name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=487471&group_id=5470 From noreply at sourceforge.net Thu Oct 30 14:07:53 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 14:07:59 2003 Subject: [Python-bugs-list] [ python-Bugs-661042 ] urllib2 and proxy Message-ID: Bugs item #661042, was opened at 2003-01-02 11:32 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661042&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Jean-Marc Desprez (jmdesprez) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 and proxy Initial Comment: the following code fails to open the url, through a proxy (it tries to connect directly, as if no proxy was supplied) #! /usr/bin/env python import urllib2 if __name__ == "__main__": h_prox = urllib2.ProxyHandler({'http' : 'http://10.4.4.123:3128'}) #opner = urllib2.build_opener(h_prox, urllib2.HTTPHandler) opner = urllib2.build_opener(h_prox) urllib2.install_opener(opner) urllib2.urlopen('http://www.python.org') but it works if I add ' urllib2.HTTPHandler' in build_opener call (commented line) It seems that 'urllib2:build_opener' calls first 'urllib2:OpenerDirector.add_handler' with all default handlers (including HTTPhandler when not supplied in 'build_opener'), and after the user supplied handlers,so the proxy handler is linked in second position in 'OpenerDirector.handle_open['http'], whereas it should be first in the open chain. I checked my theory with a quick and dirty hack in 'add_handler', to force instance of ProxyHandler to be inserted first in the handler_open['http'] list (it works), but I think a more apropriated fix shoud be done in 'build_opener' regards ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-10-30 19:07 Message: Logged In: YES user_id=261020 As for 487471, this should be closed -- a handler_order attribute was added to solve this a while ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661042&group_id=5470 From noreply at sourceforge.net Thu Oct 30 15:46:07 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 15:46:17 2003 Subject: [Python-bugs-list] [ python-Bugs-661042 ] urllib2 and proxy Message-ID: Bugs item #661042, was opened at 2003-01-02 11:32 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661042&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jean-Marc Desprez (jmdesprez) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 and proxy Initial Comment: the following code fails to open the url, through a proxy (it tries to connect directly, as if no proxy was supplied) #! /usr/bin/env python import urllib2 if __name__ == "__main__": h_prox = urllib2.ProxyHandler({'http' : 'http://10.4.4.123:3128'}) #opner = urllib2.build_opener(h_prox, urllib2.HTTPHandler) opner = urllib2.build_opener(h_prox) urllib2.install_opener(opner) urllib2.urlopen('http://www.python.org') but it works if I add ' urllib2.HTTPHandler' in build_opener call (commented line) It seems that 'urllib2:build_opener' calls first 'urllib2:OpenerDirector.add_handler' with all default handlers (including HTTPhandler when not supplied in 'build_opener'), and after the user supplied handlers,so the proxy handler is linked in second position in 'OpenerDirector.handle_open['http'], whereas it should be first in the open chain. I checked my theory with a quick and dirty hack in 'add_handler', to force instance of ProxyHandler to be inserted first in the handler_open['http'] list (it works), but I think a more apropriated fix shoud be done in 'build_opener' regards ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-10-30 19:07 Message: Logged In: YES user_id=261020 As for 487471, this should be closed -- a handler_order attribute was added to solve this a while ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661042&group_id=5470 From noreply at sourceforge.net Thu Oct 30 17:39:04 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 17:39:08 2003 Subject: [Python-bugs-list] [ python-Bugs-833405 ] urllib.urlencode doesn't work for output from cgi.parse_qs Message-ID: Bugs item #833405, was opened at 2003-10-30 17: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=833405&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Myers Carpenter (myers_carpenter) Assigned to: Nobody/Anonymous (nobody) Summary: urllib.urlencode doesn't work for output from cgi.parse_qs Initial Comment: >>> urllib.urlencode(cgi.parse_qsl('ext=.jpg&outquality=56')) 'ext=.jpg&outquality=56' >>> urllib.urlencode(cgi.parse_qs('ext=.jpg&outquality=56')) 'ext=%5B%27.jpg%27%5D&outquality=%5B%2756%27%5D' "%5B%27" = "['" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833405&group_id=5470 From noreply at sourceforge.net Thu Oct 30 22:04:27 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Thu Oct 30 22:05:05 2003 Subject: [Python-bugs-list] [ 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 zephyrfalcon 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: Later Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Neal Norwitz (nnorwitz) 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: 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 #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 #include --------------------------------------------------------------------------- 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 #include #include #include 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" To: "Ralf W. Grosse-Kunstleve" 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 #include . . . 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 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 Fri Oct 31 05:02:57 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 05:03:06 2003 Subject: [Python-bugs-list] [ python-Bugs-703198 ] os.popen with mode "rb" fails on Unix Message-ID: Bugs item #703198, was opened at 2003-03-13 21:35 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703198&group_id=5470 Category: Python Library Group: Python 2.1.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: J. Peterson (isonno) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen with mode "rb" fails on Unix Initial Comment: On Windows, it's necessary to use the mode "rb" to open a binary stream to a process. On Unix the "b" modifier isn't necessary, but supplying it causes the popen call to fail with OSError: [Errno 22] Invalid argument The Unix version of popen should accept and simply ignore the "b" modifier to the mode, rather than fail. That way the same code can run on both platforms without modification or extra code to special case an OS that may need the "b" modifier. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 11:02 Message: Logged In: YES user_id=21627 Fixed with said patch. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-08-22 10:47 Message: Logged In: YES user_id=139865 See patch 788404 for a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=703198&group_id=5470 From noreply at sourceforge.net Fri Oct 31 05:05:24 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 05:05:27 2003 Subject: [Python-bugs-list] [ python-Bugs-832799 ] Please link modules with shared lib Message-ID: Bugs item #832799, was opened at 2003-10-30 02:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: Please link modules with shared lib Initial Comment: We've been working with libraries that are loaded with dlopen (on Linux and Solaris, the land of ELF) and which, in turn, use the embedded python interpreter. Due to the behavior of the dynamic linker, this would work much better if modules were, by default, linked with -lpython2.3 instead of just left with hanging undefined symbols. Here's why. The main executable isn't linked with python, and none of it's direct dependents are. So, the python symbols aren't in the global namespace. The dlopened library is linked with python. However, when the dlopened library dlopens the modules, the linux linker is not clever enough to allow the second- order library to use symbols from its parent. (Solaris has such a feature, but not linux). So, one has to manually dlopen the python library with RTLD_GLOBAL to make it work. If each module had a NEED for the python lib (via -l at linktime), all this would just work. I've got some local patches to build_ext.py for this purpose, but it would be nice to have official support. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 11:05 Message: Logged In: YES user_id=21627 Please do provide patches. Take into account that modules may be built either with distutils, or through Modules/Setup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 From noreply at sourceforge.net Fri Oct 31 05:06:00 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 05:06:09 2003 Subject: [Python-bugs-list] [ python-Bugs-832251 ] Wrong reference for specific minidom methods Message-ID: Bugs item #832251, was opened at 2003-10-29 10:39 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832251&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Francesco Ricciardi (nerby) >Assigned to: Martin v. L?wis (loewis) Summary: Wrong reference for specific minidom methods Initial Comment: In the HTML documentation the method in section 13.7.1 "DOM Objects" of the library reference are listed as HTMLParser method. In the "paper" documentation (PDF-A4 and Ps-A4) the same methods have no module reference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832251&group_id=5470 From noreply at sourceforge.net Fri Oct 31 07:22:55 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 07:23:01 2003 Subject: [Python-bugs-list] [ python-Bugs-832799 ] Please link modules with shared lib Message-ID: Bugs item #832799, was opened at 2003-10-29 20:36 Message generated for change (Comment added) made by benson_basis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: Please link modules with shared lib Initial Comment: We've been working with libraries that are loaded with dlopen (on Linux and Solaris, the land of ELF) and which, in turn, use the embedded python interpreter. Due to the behavior of the dynamic linker, this would work much better if modules were, by default, linked with -lpython2.3 instead of just left with hanging undefined symbols. Here's why. The main executable isn't linked with python, and none of it's direct dependents are. So, the python symbols aren't in the global namespace. The dlopened library is linked with python. However, when the dlopened library dlopens the modules, the linux linker is not clever enough to allow the second- order library to use symbols from its parent. (Solaris has such a feature, but not linux). So, one has to manually dlopen the python library with RTLD_GLOBAL to make it work. If each module had a NEED for the python lib (via -l at linktime), all this would just work. I've got some local patches to build_ext.py for this purpose, but it would be nice to have official support. ---------------------------------------------------------------------- >Comment By: benson margulies (benson_basis) Date: 2003-10-31 07:22 Message: Logged In: YES user_id=876734 To turn my patches into things that anyone else would want, I need to know what to put in the -L that will be required. At the time we're building the main python distro, that's straightforward. When a user builds an individual module, is there a sensible path relative to PYTHONHOME I can use? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 05:05 Message: Logged In: YES user_id=21627 Please do provide patches. Take into account that modules may be built either with distutils, or through Modules/Setup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 From noreply at sourceforge.net Fri Oct 31 07:45:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 07:47:18 2003 Subject: [Python-bugs-list] [ python-Bugs-831747 ] httplib hardcodes Accept-Encoding Message-ID: Bugs item #831747, was opened at 2003-10-28 14:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831747&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: httplib hardcodes Accept-Encoding Initial Comment: in httplib.py the request() method adds a hardcoded Accept-Encoding header with the 'identity' value. This should at least be optional, since I have several programs supporting encodings like 'gzip' or 'deflate' and I want to be able to specify my own Accept-Encoding header. I suggest adding (similar to skip_host) a skip_accept_encoding optional argument. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 13:45 Message: Logged In: YES user_id=21627 Can you provide a patch (including documentation changes)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831747&group_id=5470 From noreply at sourceforge.net Fri Oct 31 08:42:51 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 08:42:58 2003 Subject: [Python-bugs-list] [ python-Bugs-832799 ] Please link modules with shared lib Message-ID: Bugs item #832799, was opened at 2003-10-30 02:36 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: benson margulies (benson_basis) Assigned to: Nobody/Anonymous (nobody) Summary: Please link modules with shared lib Initial Comment: We've been working with libraries that are loaded with dlopen (on Linux and Solaris, the land of ELF) and which, in turn, use the embedded python interpreter. Due to the behavior of the dynamic linker, this would work much better if modules were, by default, linked with -lpython2.3 instead of just left with hanging undefined symbols. Here's why. The main executable isn't linked with python, and none of it's direct dependents are. So, the python symbols aren't in the global namespace. The dlopened library is linked with python. However, when the dlopened library dlopens the modules, the linux linker is not clever enough to allow the second- order library to use symbols from its parent. (Solaris has such a feature, but not linux). So, one has to manually dlopen the python library with RTLD_GLOBAL to make it work. If each module had a NEED for the python lib (via -l at linktime), all this would just work. I've got some local patches to build_ext.py for this purpose, but it would be nice to have official support. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 14:42 Message: Logged In: YES user_id=21627 You can probably rely on libpythonxy.so ending up in $(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can retrieve from the installed Makefile (i.e. through distutils.config). ---------------------------------------------------------------------- Comment By: benson margulies (benson_basis) Date: 2003-10-31 13:22 Message: Logged In: YES user_id=876734 To turn my patches into things that anyone else would want, I need to know what to put in the -L that will be required. At the time we're building the main python distro, that's straightforward. When a user builds an individual module, is there a sensible path relative to PYTHONHOME I can use? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 11:05 Message: Logged In: YES user_id=21627 Please do provide patches. Take into account that modules may be built either with distutils, or through Modules/Setup. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832799&group_id=5470 From noreply at sourceforge.net Fri Oct 31 09:55:26 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 09:55:30 2003 Subject: [Python-bugs-list] [ python-Bugs-831747 ] httplib hardcodes Accept-Encoding Message-ID: Bugs item #831747, was opened at 2003-10-28 14:38 Message generated for change (Comment added) made by calvin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831747&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: httplib hardcodes Accept-Encoding Initial Comment: in httplib.py the request() method adds a hardcoded Accept-Encoding header with the 'identity' value. This should at least be optional, since I have several programs supporting encodings like 'gzip' or 'deflate' and I want to be able to specify my own Accept-Encoding header. I suggest adding (similar to skip_host) a skip_accept_encoding optional argument. ---------------------------------------------------------------------- >Comment By: Bastian Kleineidam (calvin) Date: 2003-10-31 15:55 Message: Logged In: YES user_id=9205 Yes, in a few days. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 13:45 Message: Logged In: YES user_id=21627 Can you provide a patch (including documentation changes)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831747&group_id=5470 From noreply at sourceforge.net Fri Oct 31 10:22:28 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 10:23:00 2003 Subject: [Python-bugs-list] [ python-Bugs-831574 ] Solaris term.h needs curses.h Message-ID: Bugs item #831574, was opened at 2003-10-28 07:53 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831574&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Solaris term.h needs curses.h Initial Comment: Solaris' term.h requires curses.h to be included first. This causes the configure script to emit lines about a bug in autoconf. From the autoconf mailing lists, their standard response is to fix the configure script, see e.g. http://mail.gnu.org/archive/html/bug-autoconf/2003-05/msg00118.html The following patch against 2.3 branch for configure and configure.in makes things a bit happier. Note that Include/py_curses.h already includes curses.h before term.h, this just fixes the breakage of configure. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2003-10-31 16:22 Message: Logged In: YES user_id=21627 I find it confusing that the test for curses.h already refers to HAVE_CURSES_H; I think you should first check for curses.h, and then use HAVE_CURSES_H in the test for term.h I also agree that #ifdef is better than #if, even though it should not matter in an ISO C compiler (which replaces undefined symbols by 0 in an #if). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-10-29 02:38 Message: Logged In: YES user_id=29957 Dunno if #ifdef is better or not - I just worked from the example in the attached autoconf mailing list message. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-10-28 14:08 Message: Logged In: YES user_id=33168 Should the #if be an #ifdef ? Looks fine to me, but I don't know much about autoconf. :-) I think Martin is the expert. Martin do you have an opinion? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=831574&group_id=5470 From noreply at sourceforge.net Fri Oct 31 14:14:47 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 14:14:55 2003 Subject: [Python-bugs-list] [ python-Bugs-829532 ] os.makedirs() cannot handle "." Message-ID: Bugs item #829532, was opened at 2003-10-24 07:44 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) >Assigned to: A.M. Kuchling (akuchling) Summary: os.makedirs() cannot handle "." Initial Comment: Invoking os.makedirs() with an argument that contains a directory name with a single dot fails. The resulting error is confusing: "File exists". The problem is that the path is split up in pieces and an attempt is made to create the "." directory. This always exists, of course. It happens anyway, because the test for existence is done before creating the directory that contains ".". There are various possible solutions: 1. First normalize the path so that "." entries are removed. This would also work for ".." entries. But it might cause trouble for symbolic links and there is a performance penalty. 2. Check for existence of the directory again after the recursive call to create the directory that contains the entry. This will cause the normal error for an existing directory to be skipped, unless an extra flag is added. This gets complicated. 3. Simply skip creating a directory with the name ".". I propose to use the third solution. I have attached a patch for this. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-10-27 19:54 Message: Logged In: YES user_id=539787 Minor correction (in ex cmdline style :): :%s/"\."/curdir/g in the 'diff' patch (making it more OS independent). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-10-24 13:46 Message: Logged In: YES user_id=11375 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 From noreply at sourceforge.net Fri Oct 31 14:27:10 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 14:27:14 2003 Subject: [Python-bugs-list] [ python-Bugs-819510 ] httplib.SSLFile lacks readlines() method Message-ID: Bugs item #819510, was opened at 2003-10-07 15:32 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819510&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Matthew Campbell (mattcamp) Assigned to: Nobody/Anonymous (nobody) Summary: httplib.SSLFile lacks readlines() method Initial Comment: The httplib.SSLFile class has no readlines() method. A readlines() method is necessary if the SSL server sends back an HTTP/0.9 response, since in that case, the httplib.LineAndFileWrapper class is used. The_done () method in httplib.LineAndFileWrapper has this statement: self.readlines = self._file.readlines Which causes an error when "self._file" refers to SSLFile. This happens even if I only call the read() method on LineAndFileWrapper. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-10-31 14:27 Message: Logged In: YES user_id=11375 Patch #817854 has been committed, so this bug can be closed. ---------------------------------------------------------------------- Comment By: Andrew Gaul (gaul) Date: 2003-10-09 23:50 Message: Logged In: YES user_id=139865 This is a duplicate of bug #792101. Patch #817854 may provide a fix but needs to be reviewed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=819510&group_id=5470 From noreply at sourceforge.net Fri Oct 31 14:41:16 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 14:41:22 2003 Subject: [Python-bugs-list] [ python-Bugs-829532 ] os.makedirs() cannot handle "." Message-ID: Bugs item #829532, was opened at 2003-10-24 07:44 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: A.M. Kuchling (akuchling) Summary: os.makedirs() cannot handle "." Initial Comment: Invoking os.makedirs() with an argument that contains a directory name with a single dot fails. The resulting error is confusing: "File exists". The problem is that the path is split up in pieces and an attempt is made to create the "." directory. This always exists, of course. It happens anyway, because the test for existence is done before creating the directory that contains ".". There are various possible solutions: 1. First normalize the path so that "." entries are removed. This would also work for ".." entries. But it might cause trouble for symbolic links and there is a performance penalty. 2. Check for existence of the directory again after the recursive call to create the directory that contains the entry. This will cause the normal error for an existing directory to be skipped, unless an extra flag is added. This gets complicated. 3. Simply skip creating a directory with the name ".". I propose to use the third solution. I have attached a patch for this. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-10-31 14:41 Message: Logged In: YES user_id=11375 Note that the documentation for os.makedirs() says it raises an exception if the directory already exists, so os.makedirs('.') has to continue to be an error, though os.makedirs('/foo/bar/.') should be made to work properly. The attached patch implements this. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-10-27 19:54 Message: Logged In: YES user_id=539787 Minor correction (in ex cmdline style :): :%s/"\."/curdir/g in the 'diff' patch (making it more OS independent). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-10-24 13:46 Message: Logged In: YES user_id=11375 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 From noreply at sourceforge.net Fri Oct 31 14:41:49 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 14:41:55 2003 Subject: [Python-bugs-list] [ python-Bugs-832535 ] Inconsitent line numbering in traceback Message-ID: Bugs item #832535, was opened at 2003-10-29 12:48 Message generated for change (Comment added) made by jemfinch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832535&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsitent line numbering in traceback Initial Comment: Transcript below documents the problem. A traceback shows a line with no float() op, but complains of a float op error. I restart the shell, with no changes to the imported module, and this time line 45 is correctly listed. >>> reload(brawley) >>> brawley.test2() elems: 3, 4, 5, 0.5, 'White', sublist: 7,8,9] ['3', ' 4', ' 5', ' 0.5', " 'White'", ' '] ['3', ' 4', ' 5', ' 0.5', " 'White'"] Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 color = elems[-2] ValueError: invalid literal for float(): 'White >>> ================================ RESTART ================================ >>> import brawley >>> brawley.test2() elems: 3, 4, 5, 0.5, 'White', sublist: 7,8,9] ['3', ' 4', ' 5', ' 0.5', " 'White'", ' '] ['3', ' 4', ' 5', ' 0.5', " 'White'"] Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 x,y,z,radius = [float(i) for i in elems[:-3].split(',')] ValueError: invalid literal for float(): 'White ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-10-31 14:41 Message: Logged In: YES user_id=99508 Yeah, this is definitely the linecache problem. Is there a good reason why reload doesn't do a linecache.checkcache itself? I really doubt reload is being called inside performance-sensitive code. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-29 13:02 Message: Logged In: YES user_id=6656 Is this the hoary old "being lied to by linecache" thing? I complain about that every now and again, but haven't actually done anything about it yet... ---------------------------------------------------------------------- Comment By: Kirby Urner (urnerk) Date: 2003-10-29 12:56 Message: Logged In: YES user_id=191709 It's a little more serious. After a save/reload, the traceback will echo code that's no longer present in the source at all. Traceback (most recent call last): File "", line 1, in -toplevel- brawley.test2() File "C:\Documents and Settings\Kirby\My Documents\FreeGeek\PythonicGeom\brawley.py", line 45, in test2 x,y,z,radius = [float(i) for i in elems[:-3].split(',')] ValueError: invalid literal for float(): 'White' But line 45 in the saved/reloaded source is really: x,y,z,radius = [float(i) for i in elems.split(',')[:-1]] When I restart the shell and import, the real source code is echoed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832535&group_id=5470 From noreply at sourceforge.net Fri Oct 31 14:53:19 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 14:53:45 2003 Subject: [Python-bugs-list] [ python-Bugs-817178 ] Email.message example missing arg Message-ID: Bugs item #817178, was opened at 2003-10-03 09:54 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817178&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Terry J. Reedy (tjreedy) >Assigned to: A.M. Kuchling (akuchling) Summary: Email.message example missing arg Initial Comment: LIb Ref 12.2.3 Generating MIME documents says ''' class Generator( outfp[, mangle_from_[, maxheaderlen]]) The constructor for the Generator class takes a file-like object called outfp for an argument. outfp must support the write() method and be usable as the output file in a Python extended print statement. ''' 12.2.1 Representing an email message has example ''' from cStringIO import StringIO from email.Generator import Generator fp = StringIO() g = Generator(mangle_from_=False, maxheaderlen=60) ... ''' It seems prett clear that fp should be added as first arg of Generator call. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-10-31 14:53 Message: Logged In: YES user_id=11375 Well spotted! I've fixed this on both the CVS trunk and the 2.3 maintenance branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=817178&group_id=5470 From noreply at sourceforge.net Fri Oct 31 17:06:33 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 17:06:41 2003 Subject: [Python-bugs-list] [ python-Bugs-833905 ] Incorrect priority 'in' and '==' Message-ID: Bugs item #833905, was opened at 2003-10-31 22: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=833905&group_id=5470 Category: Documentation Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Roth (jhrothjr) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect priority 'in' and '==' Initial Comment: Section 5.9 of the LRM specifies that 'in' and 'is' are treated the same as '=='. However, the priority chart in the 5.14 Summary part of chapter 5 gives them different priorities. This leads one to expect that 'a' in 'abc' == 1 should parse as if it was 'a' in ('abc' == 1) while it actually parses as ('a' in 'abc') == 1. The priority chart in the LRM should be corrected to put both 'is' and 'in' on the same line with the other conditionals. It would also be nice if a note pointed out that all of the operators on this line exhibit short circuit behavior, and also that this is not a change from prior releases. See the discussion on c.l.py beginning on 10/30/2003 titled Boolean Confusion. The first post is by Frantisek Fuka. I've put it under 2.2.3 only because I don't have the 2.3.2 manual to hand. I believe the original report on c.l.py was under 2.3.2 John Roth ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833905&group_id=5470 From noreply at sourceforge.net Fri Oct 31 17:10:31 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 17:10:40 2003 Subject: [Python-bugs-list] [ python-Bugs-829532 ] os.makedirs() cannot handle "." Message-ID: Bugs item #829532, was opened at 2003-10-24 13:44 Message generated for change (Comment added) made by vimboss You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bram Moolenaar (vimboss) Assigned to: A.M. Kuchling (akuchling) Summary: os.makedirs() cannot handle "." Initial Comment: Invoking os.makedirs() with an argument that contains a directory name with a single dot fails. The resulting error is confusing: "File exists". The problem is that the path is split up in pieces and an attempt is made to create the "." directory. This always exists, of course. It happens anyway, because the test for existence is done before creating the directory that contains ".". There are various possible solutions: 1. First normalize the path so that "." entries are removed. This would also work for ".." entries. But it might cause trouble for symbolic links and there is a performance penalty. 2. Check for existence of the directory again after the recursive call to create the directory that contains the entry. This will cause the normal error for an existing directory to be skipped, unless an extra flag is added. This gets complicated. 3. Simply skip creating a directory with the name ".". I propose to use the third solution. I have attached a patch for this. ---------------------------------------------------------------------- >Comment By: Bram Moolenaar (vimboss) Date: 2003-10-31 23:10 Message: Logged In: YES user_id=57665 The patch suggested by akuchling doesn't work for "dir/./.". And the remark is false anyway, the patch I suggested does generate an exception for makedirs("."). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-10-31 20:41 Message: Logged In: YES user_id=11375 Note that the documentation for os.makedirs() says it raises an exception if the directory already exists, so os.makedirs('.') has to continue to be an error, though os.makedirs('/foo/bar/.') should be made to work properly. The attached patch implements this. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-10-28 01:54 Message: Logged In: YES user_id=539787 Minor correction (in ex cmdline style :): :%s/"\."/curdir/g in the 'diff' patch (making it more OS independent). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2003-10-24 19:46 Message: Logged In: YES user_id=11375 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=829532&group_id=5470 From noreply at sourceforge.net Fri Oct 31 19:27:54 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 19:27:57 2003 Subject: [Python-bugs-list] [ python-Bugs-833957 ] Ctrl+key combos stop working in IDLE Message-ID: Bugs item #833957, was opened at 2003-10-31 16: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=833957&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirby Urner (urnerk) Assigned to: Nobody/Anonymous (nobody) Summary: Ctrl+key combos stop working in IDLE Initial Comment: After awhile using Python 2.3 IDLE in Windows, the control keys such as Ctrl+C (copy) and Ctrl+V (paste) stop having any effect. Menu pulldowns continue to work. I have yet to notice what circumstances might trigger this behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833957&group_id=5470 From noreply at sourceforge.net Fri Oct 31 20:32:01 2003 From: noreply at sourceforge.net (SourceForge.net) Date: Fri Oct 31 20:32:08 2003 Subject: [Python-bugs-list] [ python-Bugs-754509 ] mod_python does't compile Message-ID: Bugs item #754509, was opened at 2003-06-14 15:29 Message generated for change (Comment added) made by ivan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754509&group_id=5470 Category: Build Group: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: Phil Hughes (fyl) Assigned to: Nobody/Anonymous (nobody) Summary: mod_python does't compile Initial Comment: When I attempt to build mod_python 3.0.3 on Linux (SuSE 8.2) it fails with requestobject.c: In function `getreq_recmbr_off': requestobject.c:1055: error: `LONG_LONG' undeclared (first use in this function) ---------------------------------------------------------------------- Comment By: Ivan Havlicek (ivan) Date: 2003-11-01 02:32 Message: Logged In: YES user_id=18638 Hi, I've the same problem (Python-2.3.2/mod_python-3.0.3) I've found this message : http://mail.python.org/pipermail/python-dev/2003-April/034396.html so I change LONG_LONG by PY_LONG_LONG in requestobject.c and... it compile ! I hope it'll work well now ;-)) -- Ivan ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2003-06-14 16:12 Message: Logged In: YES user_id=21627 This is not a bug in Python, but in mod_python. Please report it to the mod_python maintainer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754509&group_id=5470 From JF.Simon at ulg.ac.be Wed Oct 29 06:51:08 2003 From: JF.Simon at ulg.ac.be (=?ISO-8859-1?Q?Jean-Fran=E7ois_Simon?=) Date: Sat Nov 8 17:09:44 2003 Subject: dl module on 64 bit processor Message-ID: <3F9FA9AC.4060303@ulg.ac.be> Hi everybody, I hope I'm on the right list. If not please, redirect me. I use mayavi, a data visualizator. It's based on VTK graphic librairies and is write in python. After installing the today version vtk on a alpha processor, I get this message error : File "/usr/bin/mayavi", line 282, in ? import mayavi File "/usr/lib/python2.1/site-packages/mayavi/__init__.py", line 5, in ? import Common, Base.Objects File "/usr/lib/python2.1/site-packages/mayavi/Base/__init__.py", line 19, in ? import Objects File "/usr/lib/python2.1/site-packages/mayavi/Base/Objects.py", line 20, in ? import Tkinter, vtkpython, math, tkColorChooser File "/usr/lib/python2.1/site-packages/vtk_python/vtkpython.py", line 7, in ? from vtk import * File "/usr/lib/python2.1/site-packages/vtk_python/vtk/__init__.py", line 9, in ? import dl SystemError: module dl requires sizeof(int) == sizeof(long) == sizeof(char*) I replace the __init__.py file ( .../vtk_python/vtk/__init__.py) by the older one of the version 4.2 of VTK, that not call the dl module and everything went all right. The problem of the dl module with 64 bit processor has been adressed here : http://mail.python.org/pipermail/python-checkins/2002-September/029564.html So I'm asking if it's not possible to include a check on architecture of the processor and skip the call of the dl module ? And what is the utility of the dl module ? Why is it reintroduce in the current version of VTK wrapping python ? Thanks in advance Jean-Fran?ois