From noreply@sourceforge.net Tue Jul 1 00:43:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 16:43:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 00:33 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-30 16:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 05:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Tue Jul 1 02:46:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 18:46:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 00:33 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-30 18:46 Message: Logged In: YES user_id=357491 So it wasn't what I thought it would be. But I do think I found the error. Dmitry, can you apply the patch that I attached to the report and see if it fixes the problem? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 16:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 05:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Tue Jul 1 02:50:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 18:50:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-763052 ] test_winsound, test_strptime fails in win2k Message-ID: Bugs item #763052, was opened at 2003-06-30 00:47 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Brett Cannon (bcannon) Summary: test_winsound, test_strptime fails in win2k Initial Comment: Hello, D:\apps\Python23>python -c "from test import test_winsound;test_winsound.test_ma in()" test_errors (test.test_winsound.BeepTest) ... ok test_extremes (test.test_winsound.BeepTest) ... ok test_increasingfrequency (test.test_winsound.BeepTest) ... ok test_asterisk (test.test_winsound.MessageBeepTest) ... ok test_default (test.test_winsound.MessageBeepTest) ... ok test_exclamation (test.test_winsound.MessageBeepTest) ... ok test_hand (test.test_winsound.MessageBeepTest) ... ok test_ok (test.test_winsound.MessageBeepTest) ... ok test_question (test.test_winsound.MessageBeepTest) ... ok test_alias_asterisk (test.test_winsound.PlaySoundTest) ... ok test_alias_exclamation (test.test_winsound.PlaySoundTest) ... ok test_alias_exit (test.test_winsound.PlaySoundTest) ... ok test_alias_fallback (test.test_winsound.PlaySoundTest) ... ok test_alias_hand (test.test_winsound.PlaySoundTest) ... ok test_alias_nofallback (test.test_winsound.PlaySoundTest) ... ok test_alias_question (test.test_winsound.PlaySoundTest) ... ok test_errors (test.test_winsound.PlaySoundTest) ... ok test_stopasync (test.test_winsound.PlaySoundTest) ... FAIL ====================================================================== FAIL: test_stopasync (test.test_winsound.PlaySoundTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------------------------------------------------- Ran 18 tests in 6.199s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_winsound.py", line 99, in test_main test_support.run_unittest(BeepTest, MessageBeepTest, PlaySoundTest) File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------- D:\apps\Python23>python -c "from test import test_strptime; test_strptime.test_m ain()" test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok test_by_hand_input (test.test_strptime.LocaleTime_Tests) ... ok test_date_time (test.test_strptime.LocaleTime_Tests) ... ok test_lang (test.test_strptime.LocaleTime_Tests) ... ok test_month (test.test_strptime.LocaleTime_Tests) ... ok test_timezone (test.test_strptime.LocaleTime_Tests) ... ok test_unknowntimezone (test.test_strptime.LocaleTime_Tests) ... ok test_weekday (test.test_strptime.LocaleTime_Tests) ... ok test_blankpattern (test.test_strptime.TimeRETests) ... ok test_compile (test.test_strptime.TimeRETests) ... ok test_getitem (test.test_strptime.TimeRETests) ... ok test_matching_with_escapes (test.test_strptime.TimeRETests) ... ok test_pattern (test.test_strptime.TimeRETests) ... ok test_pattern_escaping (test.test_strptime.TimeRETests) ... ok test_TypeError (test.test_strptime.StrptimeTests) ... ok test_caseinsensitive (test.test_strptime.StrptimeTests) ... ok test_date (test.test_strptime.StrptimeTests) ... ok test_date_time (test.test_strptime.StrptimeTests) ... ok test_day (test.test_strptime.StrptimeTests) ... ok test_defaults (test.test_strptime.StrptimeTests) ... ok test_hour (test.test_strptime.StrptimeTests) ... ok test_julian (test.test_strptime.StrptimeTests) ... ok test_minute (test.test_strptime.StrptimeTests) ... ok test_month (test.test_strptime.StrptimeTests) ... ok test_percent (test.test_strptime.StrptimeTests) ... ok test_second (test.test_strptime.StrptimeTests) ... ok test_time (test.test_strptime.StrptimeTests) ... ok test_timezone (test.test_strptime.StrptimeTests) ... FAIL test_unconverteddata (test.test_strptime.StrptimeTests) ... ok test_weekday (test.test_strptime.StrptimeTests) ... ok test_year (test.test_strptime.StrptimeTests) ... ok test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests) ... ok test_all_julian_days (test.test_strptime.JulianTests) ... ok test_day_of_week_calculation (test.test_strptime.CalculationTests) ... ok test_gregorian_calculation (test.test_strptime.CalculationTests) ... ok test_julian_calculation (test.test_strptime.CalculationTests) ... ok ====================================================================== FAIL: test_timezone (test.test_strptime.StrptimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- Ran 36 tests in 0.330s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_strptime.py", line 421, in test_main CalculationTests File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-30 18:49 Message: Logged In: YES user_id=357491 Miki, can you follow the test_strptime issues on bug #763047 ? It is the same problem and it will be easier to manage if you can follow along there. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 05:03 Message: Logged In: YES user_id=89016 The most likely reason for the winsound failure is, that your "SystemQuestion" sound has already finished before the second one starts, so there will be no RuntimeError exception. Checked in a fix as: Lib/test/test_winsound.py 1.6 Assigning to Brett Cannon for the strptime stuff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 From noreply@sourceforge.net Tue Jul 1 03:28:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 19:28:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-763637 ] 2.3b2 unpack tuple of wrong size in after_cancel Message-ID: Bugs item #763637, was opened at 2003-06-30 21: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=763637&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3b2 unpack tuple of wrong size in after_cancel Initial Comment: The new code in after_cancel in the version of Tkinter.py that ships with 2.3b2: (script, type) = self.tk.splitlist( self.tk.call('after', 'info', id)) fails because the splitlist call returns something like ('after#53',) at least when linking against the Tcl and Tk 8.4 libraries that Fink installs under Mac OS X. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763637&group_id=5470 From noreply@sourceforge.net Tue Jul 1 03:38:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 19:38:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 07:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Will (towi) >Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 21:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 12:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 10:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Tue Jul 1 03:49:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 19:49:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-763362 ] test_posixpath failed Message-ID: Bugs item #763362, was opened at 2003-06-30 12:01 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763362&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) >Assigned to: Walter Dörwald (doerwalter) Summary: test_posixpath failed Initial Comment: I get the following with current cvs on Tru64Unix 5.1A: test_posix test_posixpath test test_posixpath failed -- Traceback (most recent call last): File "/mnt/python/dist/src/Lib/test/test_posixpath.py", line 343, in test_expanduser posixpath.expanduser("~/") File "/mnt/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: '//' != '/' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763362&group_id=5470 From noreply@sourceforge.net Tue Jul 1 04:00:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 20:00:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-750328 ] Pickle fails to restore new-style class instance in a cycle Message-ID: Bugs item #750328, was opened at 2003-06-06 16:13 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&group_id=5470 Category: Type/class unification Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Phillip J. Eby (pje) Assigned to: Nobody/Anonymous (nobody) Summary: Pickle fails to restore new-style class instance in a cycle Initial Comment: Here is code to demonstrate the problem. All asserts succeed except the last, showing that pickle and cPickle both handle a "classic" cycle correctly, but only cPickle handles new-style cycles correctly. It would appear that the problem is that the pure-Python pickle isn't putting the object into its 'memo' until *after* the object's state has been pickled. Thus, the identity is not preserved on unpickling. This may be true for other object types that use __reduce__, but I have not verified this. import pickle, cPickle class X: pass x = X() x.x = x x2 = cPickle.loads(cPickle.dumps(x)) assert x2.x is x2 x2 = pickle.loads(pickle.dumps(x)) assert x2.x is x2 class Y(object): pass y = Y() y.y = y y2 = cPickle.loads(cPickle.dumps(y)) assert y2.y is y2 # this fails y2 = pickle.loads(pickle.dumps(y)) assert y2.y is y2 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 22:00 Message: Logged In: YES user_id=80475 Another datapoint: This above script runs fine in Py2.3b2. ---------------------------------------------------------------------- Comment By: Steven Taschuk (staschuk) Date: 2003-06-08 15:23 Message: Logged In: YES user_id=666873 Compare bug 702858, which observes the same behaviour for copy.deepcopy. The common parts of pickle and copy really ought to be merged. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=750328&group_id=5470 From noreply@sourceforge.net Tue Jul 1 04:34:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 20:34:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-763362 ] test_posixpath failed Message-ID: Bugs item #763362, was opened at 2003-06-30 13:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763362&group_id=5470 Category: Demos and Tools Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) >Assigned to: Neal Norwitz (nnorwitz) Summary: test_posixpath failed Initial Comment: I get the following with current cvs on Tru64Unix 5.1A: test_posix test_posixpath test test_posixpath failed -- Traceback (most recent call last): File "/mnt/python/dist/src/Lib/test/test_posixpath.py", line 343, in test_expanduser posixpath.expanduser("~/") File "/mnt/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: '//' != '/' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 23:34 Message: Logged In: YES user_id=33168 Checked in as: Lib/test/test_posixpath.py 1.9 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763362&group_id=5470 From noreply@sourceforge.net Tue Jul 1 04:36:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 20:36:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-763023 ] difflib.py: line 528 in ratio() zero division not caught Message-ID: Bugs item #763023, was opened at 2003-06-30 02:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Raymond Hettinger (rhettinger) Summary: difflib.py: line 528 in ratio() zero division not caught Initial Comment: 2.2.3 and 2.3b1: >>> from difflib import * >>> s = SequenceMatcher(None, [], []) >>> s.ratio() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/difflib.py", line 528, in ratio return 2.0 * matches / (len(self.a) + len(self.b)) ZeroDivisionError: float division ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 23:36 Message: Logged In: YES user_id=33168 How about we split the difference, say 0.5. :-) Raymond (or Tim) could you review the attached patch? Ok adding this new (non-public) function? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-30 18:29 Message: Logged In: YES user_id=31435 Heh. How a ZeroDivisionError coming out of a method named *ratio* can be a surprise is beyond me . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 11:34 Message: Logged In: YES user_id=80475 One other thought. The same fix should be made to all three ratio methods (including quick and real-quick). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 11:30 Message: Logged In: YES user_id=80475 When the denominator is zero, it means that both sequences are of zero-length; therefore, the two sequences are equal, so the return value should be 1.0. The try / except ZeroDivision error approach look good. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 11:19 Message: Logged In: YES user_id=33168 This affects 2.3 as well (line 614). The return line can be wrapped with try/except ZeroDivisionError. Raymond, should 0.0 be returned in this case? Should something else be done? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470 From noreply@sourceforge.net Tue Jul 1 04:37:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 20:37:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-763023 ] difflib.py: line 528 in ratio() zero division not caught Message-ID: Bugs item #763023, was opened at 2003-06-30 02:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Raymond Hettinger (rhettinger) Summary: difflib.py: line 528 in ratio() zero division not caught Initial Comment: 2.2.3 and 2.3b1: >>> from difflib import * >>> s = SequenceMatcher(None, [], []) >>> s.ratio() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/difflib.py", line 528, in ratio return 2.0 * matches / (len(self.a) + len(self.b)) ZeroDivisionError: float division ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 23:37 Message: Logged In: YES user_id=33168 There should be a test for this too, but I'm not real familiar with doctest. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 23:36 Message: Logged In: YES user_id=33168 How about we split the difference, say 0.5. :-) Raymond (or Tim) could you review the attached patch? Ok adding this new (non-public) function? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-30 18:29 Message: Logged In: YES user_id=31435 Heh. How a ZeroDivisionError coming out of a method named *ratio* can be a surprise is beyond me . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 11:34 Message: Logged In: YES user_id=80475 One other thought. The same fix should be made to all three ratio methods (including quick and real-quick). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 11:30 Message: Logged In: YES user_id=80475 When the denominator is zero, it means that both sequences are of zero-length; therefore, the two sequences are equal, so the return value should be 1.0. The try / except ZeroDivision error approach look good. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 11:19 Message: Logged In: YES user_id=33168 This affects 2.3 as well (line 614). The return line can be wrapped with try/except ZeroDivisionError. Raymond, should 0.0 be returned in this case? Should something else be done? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470 From noreply@sourceforge.net Tue Jul 1 04:40:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 20:40:57 -0700 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 10:58 Message generated for change (Comment added) made by nnorwitz 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: Guido van Rossum (gvanrossum) 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: Neal Norwitz (nnorwitz) Date: 2003-06-30 23: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 11: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 23: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 23: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@sourceforge.net Tue Jul 1 04:58:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 20:58:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-763637 ] 2.3b2 unpack tuple of wrong size in after_cancel Message-ID: Bugs item #763637, was opened at 2003-06-30 22:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763637&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3b2 unpack tuple of wrong size in after_cancel Initial Comment: The new code in after_cancel in the version of Tkinter.py that ships with 2.3b2: (script, type) = self.tk.splitlist( self.tk.call('after', 'info', id)) fails because the splitlist call returns something like ('after#53',) at least when linking against the Tcl and Tk 8.4 libraries that Fink installs under Mac OS X. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 23:58 Message: Logged In: YES user_id=33168 Matthew can you test the attached patch to verify if it fixes the problem. This (still) works for me on Tk 8.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763637&group_id=5470 From noreply@sourceforge.net Tue Jul 1 05:40:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 21:40:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-763023 ] difflib.py: line 528 in ratio() zero division not caught Message-ID: Bugs item #763023, was opened at 2003-06-30 01:24 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Raymond Hettinger (rhettinger) Summary: difflib.py: line 528 in ratio() zero division not caught Initial Comment: 2.2.3 and 2.3b1: >>> from difflib import * >>> s = SequenceMatcher(None, [], []) >>> s.ratio() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/difflib.py", line 528, in ratio return 2.0 * matches / (len(self.a) + len(self.b)) ZeroDivisionError: float division ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 23:40 Message: Logged In: YES user_id=80475 Looks good. See attached test to replace the existing testfile. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 22:37 Message: Logged In: YES user_id=33168 There should be a test for this too, but I'm not real familiar with doctest. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 22:36 Message: Logged In: YES user_id=33168 How about we split the difference, say 0.5. :-) Raymond (or Tim) could you review the attached patch? Ok adding this new (non-public) function? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-30 17:29 Message: Logged In: YES user_id=31435 Heh. How a ZeroDivisionError coming out of a method named *ratio* can be a surprise is beyond me . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 10:34 Message: Logged In: YES user_id=80475 One other thought. The same fix should be made to all three ratio methods (including quick and real-quick). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 10:30 Message: Logged In: YES user_id=80475 When the denominator is zero, it means that both sequences are of zero-length; therefore, the two sequences are equal, so the return value should be 1.0. The try / except ZeroDivision error approach look good. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 10:19 Message: Logged In: YES user_id=33168 This affects 2.3 as well (line 614). The return line can be wrapped with try/except ZeroDivisionError. Raymond, should 0.0 be returned in this case? Should something else be done? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470 From noreply@sourceforge.net Tue Jul 1 06:05:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 22:05:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-757520 ] irreproducable segfault on int(1e100) Message-ID: Bugs item #757520, was opened at 2003-06-19 16:19 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757520&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerrit Holl (gerrit) Assigned to: Nobody/Anonymous (nobody) Summary: irreproducable segfault on int(1e100) Initial Comment: Segmentation Fault: 20 >>> i 1e+100 21 >>> int(i)Segmentation fault 23:16:12:2:gerrit@stopcontact:~/downl$ python Python 2.3b1+ (#3, Jun 19 2003, 10:34:37) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. 0 >>> i=1e100 1 >>> int(i)Segmentation fault 23:16:21:2:gerrit@stopcontact:~/downl$ python Python 2.3b1+ (#3, Jun 19 2003, 10:34:37) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. 0 >>> i=1e100 1 >>> int(i) 10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104L I'm unable to reproduce this (sorry). I noticed before that sometimes, the interactive Python interpreter segfaults irreproducable: only now, it was two times in succession but not more than two times. I never encounered this problem while executing Python programs from scripts. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 00:05 Message: Logged In: YES user_id=80475 I tried about 50 times with the interactive interpreter and got no failures. Do you still have the same problem with a fresh download of the 2.3b2 release? Can you post anything useful for tracking down the problem? ---------------------------------------------------------------------- Comment By: Gerrit Holl (gerrit) Date: 2003-06-25 10:00 Message: Logged In: YES user_id=13298 Interestingly, the problem does not occur within a script here, too. Maybe it is in the readline library or something like that. Pressing - always segfaults for me (known readline bug). This is the same as -O- and the same problem is in Ruby and sh, so this is a readline bug. I think this because [int(1e100) for i in xrange(1000000)] works fine, also on the interactive prompt. Hmm, would there be a way to test this hypotesis? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-25 09:49 Message: Logged In: YES user_id=80475 Under Windows compiled by MSVC++, I've run this hundred thousand times in a loop without a failure. I tried it in a script and using the interpreter, so it does appear to be specific to gcc. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-21 08:44 Message: Logged In: YES user_id=21627 I suspect this is a bug in the C library. To find out for sure, one would have to study the relevant assembler code in glibc in detail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757520&group_id=5470 From noreply@sourceforge.net Tue Jul 1 06:10:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 22:10:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 05:35 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Will (towi) >Assigned to: Nobody/Anonymous (nobody) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-30 22:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 19:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 10:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 08:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Tue Jul 1 06:16:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 22:16:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-697990 ] Document strptime limitation Message-ID: Bugs item #697990, was opened at 2003-03-05 05:48 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Erland Lewin (erl) Assigned to: Brett Cannon (bcannon) Summary: Document strptime limitation Initial Comment: Python Library Reference, Chapter 6.9: strptime: Many (at least glibc 2) versions of strptime can't parse the time zone (which strftime prints with %Z). This should be mentioned as a warning in the documentation. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-06-30 22:16 Message: Logged In: YES user_id=357491 New docs checked in as revision 1.58 for the Doc/lib/libtime.tex . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 00:37 Message: Logged In: YES user_id=357491 OK, so it was agreed that _strptime will become the only implementation of time.strptime if no one gripes by the time 2.3b2 rolls around. I will fix the docs when I rip out the old C code. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-07 14:31 Message: Logged In: YES user_id=357491 So, from what I remember when Guido switched off the libc usage to get more testing of _strptime Tim was in support of just moving completely over to _strptime while Guido seemed okay with it. There was no final declaration that I know of (if there was then it was rather silly to leave in the libc wrapper code). If _strptime does turn into the only implementation I will completely flesh out the docs on _strptime and its limitations (this is one of them; been debating whether it should be able to recognize UTC and GMT as timezones beyond the two the platforms tends to know). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-05-07 05:17 Message: Logged In: YES user_id=6656 Is 2.3 going to call the libc strptime? If we keep using Brett's, presumably this is irrelevant. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-06 17:37 Message: Logged In: YES user_id=357491 I will add some note, but I don't know what yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=697990&group_id=5470 From noreply@sourceforge.net Tue Jul 1 06:31:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 22:31:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-763007 ] dl module not installed with 2.2.3 Message-ID: Bugs item #763007, was opened at 2003-06-30 00:08 Message generated for change (Comment added) made by salmo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&group_id=5470 Category: Build Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike Messmore (salmo) Assigned to: Nobody/Anonymous (nobody) Summary: dl module not installed with 2.2.3 Initial Comment: I'm running Redhat 7.3 on an older PII. I was attemping to try out the python bindings for gstreamer when I discovered my build of python 2.2.3 was lacking the 'dl' module. I've installed RPMS built from the SRPMS available on the python.org site (with the non-redhat9 spec file). Looking around I have not found a reason for this, nor a way to go about fixing it, so I assume it is a bug. Whenever I try to run a gst-python example I get an ImportError stating the the dl module does not exist, as well as when I try to run test_dl.py in my /usr/lib/python2.2/test/ directory. ---------------------------------------------------------------------- >Comment By: Mike Messmore (salmo) Date: 2003-07-01 00:31 Message: Logged In: YES user_id=121084 >From the output it seems to never try to compile dlmodule.c. I ran 'rpm --rebuild python2-2.2.3-1.src.rpm 2&>1 >python_build.txt' and grepped the resulting text for dlmodule.c and only found it placing the file in the build directory. It found dlfcn.h fine. If you need me to I can attach the python_build.txt file here, but I can't find any visable errors in the building process. By the way, feel free to let me know at any point if I'm doing something retarded. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 10:22 Message: Logged In: YES user_id=33168 What is the error when building dlmodule.c? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763007&group_id=5470 From noreply@sourceforge.net Tue Jul 1 07:41:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 23:41:07 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-585915 ] assert return values Message-ID: Feature Requests item #585915, was opened at 2002-07-24 08:28 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=585915&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Leonard (tal197) Assigned to: Nobody/Anonymous (nobody) Summary: assert return values Initial Comment: It would be nice to write: def root(x): assert x >= 0 assert return >= 0 ... or def get_path(foo): if foo is None: return None assert return is not None ... and have the 'return' assertion checked when the function exits. 'return' is already a reserved keyword so the syntax doesn't introduce any incompatibility. This might make functions more self-documenting, since asserts at the end / in the middle tend to get lost. Even if the assert goes at the end, it's still clearer, eg: def foo(): ... assert min <= return <= max return bar(min, max) vs def foo(): ... tmp = bar(min, max) assert min <= tmp <= max return tmp Thanks! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 01:41 Message: Logged In: YES user_id=80475 Yuck! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-12 21:32 Message: Logged In: YES user_id=357491 Wouldn't this require turning 'return' into an expression instead of a statement? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-07-24 10:42 Message: Logged In: YES user_id=31435 Re-opened but moved to the Feature Request tracker (it's certainly not "a bug", but there's no rule against asking for new features either, provided they're in the right place). I don't believe there's any control flow in the suggestion, just that the name "return" be taken as being bound, in assert statements, to the possibly anonyous return expression. Eiffel does something very much like this for the benefit of expressing post-conditions. I certainly agree this way of spelling it in Python has problems, though, and a PEP would be in order. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-07-24 10:06 Message: Logged In: YES user_id=31392 I don't think this is a great feature. It seems like control flow via yield or return could easily be overlooked if it's inside an assert statement. Regardless of whether I like the idea, the SF bug tracker isn't the right place to make this suggestion. The right thing to do is write a PEP describing the feature in detail, then come up with a patch to implement it. If that's too much work, but you really like the idea, you could try to drum up interest on comp.lang.python. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=585915&group_id=5470 From noreply@sourceforge.net Tue Jul 1 07:51:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 23:51:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 05:35 Message generated for change (Settings changed) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Will (towi) >Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 22:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 19:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 10:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 08:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Tue Jul 1 07:54:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 30 Jun 2003 23:54:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-763708 ] Failures in test_macostools Message-ID: Bugs item #763708, was opened at 2003-06-30 23: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=763708&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply@sourceforge.net Tue Jul 1 08:25:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 00:25:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 11:33 Message generated for change (Comment added) made by hdima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- >Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 11:25 Message: Logged In: YES user_id=388573 No, the same error remains ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 05:46 Message: Logged In: YES user_id=357491 So it wasn't what I thought it would be. But I do think I found the error. Dmitry, can you apply the patch that I attached to the report and see if it fixes the problem? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 16:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Tue Jul 1 08:42:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 00:42:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 00:33 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-01 00:42 Message: Logged In: YES user_id=357491 Damn. OK, lets take Raymond's suggestion and try removing the time.tzset call. Try the new patch and let me know how it goes. Also, when was the last time you ran the test and it passed? I am trying to isolate if this is all happening because of my attempt to take time.daylight into account. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 00:25 Message: Logged In: YES user_id=388573 No, the same error remains ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 18:46 Message: Logged In: YES user_id=357491 So it wasn't what I thought it would be. But I do think I found the error. Dmitry, can you apply the patch that I attached to the report and see if it fixes the problem? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 16:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 05:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Tue Jul 1 09:01:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 01:01:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 11:33 Message generated for change (Comment added) made by hdima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- >Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 12:01 Message: Logged In: YES user_id=388573 Maybe it may helps: locale_time.timezone is ['UTC', 'GMT', 'UTC', ''] during testing ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 11:42 Message: Logged In: YES user_id=357491 Damn. OK, lets take Raymond's suggestion and try removing the time.tzset call. Try the new patch and let me know how it goes. Also, when was the last time you ran the test and it passed? I am trying to isolate if this is all happening because of my attempt to take time.daylight into account. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 11:25 Message: Logged In: YES user_id=388573 No, the same error remains ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 05:46 Message: Logged In: YES user_id=357491 So it wasn't what I thought it would be. But I do think I found the error. Dmitry, can you apply the patch that I attached to the report and see if it fixes the problem? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 16:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Tue Jul 1 09:14:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 01:14:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-763052 ] test_winsound, test_strptime fails in win2k Message-ID: Bugs item #763052, was opened at 2003-06-30 10:47 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Brett Cannon (bcannon) Summary: test_winsound, test_strptime fails in win2k Initial Comment: Hello, D:\apps\Python23>python -c "from test import test_winsound;test_winsound.test_ma in()" test_errors (test.test_winsound.BeepTest) ... ok test_extremes (test.test_winsound.BeepTest) ... ok test_increasingfrequency (test.test_winsound.BeepTest) ... ok test_asterisk (test.test_winsound.MessageBeepTest) ... ok test_default (test.test_winsound.MessageBeepTest) ... ok test_exclamation (test.test_winsound.MessageBeepTest) ... ok test_hand (test.test_winsound.MessageBeepTest) ... ok test_ok (test.test_winsound.MessageBeepTest) ... ok test_question (test.test_winsound.MessageBeepTest) ... ok test_alias_asterisk (test.test_winsound.PlaySoundTest) ... ok test_alias_exclamation (test.test_winsound.PlaySoundTest) ... ok test_alias_exit (test.test_winsound.PlaySoundTest) ... ok test_alias_fallback (test.test_winsound.PlaySoundTest) ... ok test_alias_hand (test.test_winsound.PlaySoundTest) ... ok test_alias_nofallback (test.test_winsound.PlaySoundTest) ... ok test_alias_question (test.test_winsound.PlaySoundTest) ... ok test_errors (test.test_winsound.PlaySoundTest) ... ok test_stopasync (test.test_winsound.PlaySoundTest) ... FAIL ====================================================================== FAIL: test_stopasync (test.test_winsound.PlaySoundTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------------------------------------------------- Ran 18 tests in 6.199s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_winsound.py", line 99, in test_main test_support.run_unittest(BeepTest, MessageBeepTest, PlaySoundTest) File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------- D:\apps\Python23>python -c "from test import test_strptime; test_strptime.test_m ain()" test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok test_by_hand_input (test.test_strptime.LocaleTime_Tests) ... ok test_date_time (test.test_strptime.LocaleTime_Tests) ... ok test_lang (test.test_strptime.LocaleTime_Tests) ... ok test_month (test.test_strptime.LocaleTime_Tests) ... ok test_timezone (test.test_strptime.LocaleTime_Tests) ... ok test_unknowntimezone (test.test_strptime.LocaleTime_Tests) ... ok test_weekday (test.test_strptime.LocaleTime_Tests) ... ok test_blankpattern (test.test_strptime.TimeRETests) ... ok test_compile (test.test_strptime.TimeRETests) ... ok test_getitem (test.test_strptime.TimeRETests) ... ok test_matching_with_escapes (test.test_strptime.TimeRETests) ... ok test_pattern (test.test_strptime.TimeRETests) ... ok test_pattern_escaping (test.test_strptime.TimeRETests) ... ok test_TypeError (test.test_strptime.StrptimeTests) ... ok test_caseinsensitive (test.test_strptime.StrptimeTests) ... ok test_date (test.test_strptime.StrptimeTests) ... ok test_date_time (test.test_strptime.StrptimeTests) ... ok test_day (test.test_strptime.StrptimeTests) ... ok test_defaults (test.test_strptime.StrptimeTests) ... ok test_hour (test.test_strptime.StrptimeTests) ... ok test_julian (test.test_strptime.StrptimeTests) ... ok test_minute (test.test_strptime.StrptimeTests) ... ok test_month (test.test_strptime.StrptimeTests) ... ok test_percent (test.test_strptime.StrptimeTests) ... ok test_second (test.test_strptime.StrptimeTests) ... ok test_time (test.test_strptime.StrptimeTests) ... ok test_timezone (test.test_strptime.StrptimeTests) ... FAIL test_unconverteddata (test.test_strptime.StrptimeTests) ... ok test_weekday (test.test_strptime.StrptimeTests) ... ok test_year (test.test_strptime.StrptimeTests) ... ok test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests) ... ok test_all_julian_days (test.test_strptime.JulianTests) ... ok test_day_of_week_calculation (test.test_strptime.CalculationTests) ... ok test_gregorian_calculation (test.test_strptime.CalculationTests) ... ok test_julian_calculation (test.test_strptime.CalculationTests) ... ok ====================================================================== FAIL: test_timezone (test.test_strptime.StrptimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- Ran 36 tests in 0.330s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_strptime.py", line 421, in test_main CalculationTests File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 11:14 Message: Logged In: YES user_id=358087 Hello Brett, Sorry but no sigar (for both fixes). I'm attaching starck trace for both fixes. My time zone is GMT+2 (Jerusalem), and this is a laptop (IBM T30). Miki ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 04:49 Message: Logged In: YES user_id=357491 Miki, can you follow the test_strptime issues on bug #763047 ? It is the same problem and it will be easier to manage if you can follow along there. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 15:03 Message: Logged In: YES user_id=89016 The most likely reason for the winsound failure is, that your "SystemQuestion" sound has already finished before the second one starts, so there will be no RuntimeError exception. Checked in a fix as: Lib/test/test_winsound.py 1.6 Assigning to Brett Cannon for the strptime stuff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 From noreply@sourceforge.net Tue Jul 1 10:24:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 02:24:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-763770 ] test_socket_ssl crash Message-ID: Bugs item #763770, was opened at 2003-07-01 11:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763770&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: test_socket_ssl crash Initial Comment: test_socket test_socket_ssl test test_socket_ssl crashed -- exceptions.AttributeError: 'module' object has no attribute 'sslerror' test_socketserver test_socketserver skipped -- Use of the `network' resource not enabled test_softspace I used current cvs checkout on Tru64Unix 5.1A, cc compiled binaries. Do you need more info? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763770&group_id=5470 From noreply@sourceforge.net Tue Jul 1 10:32:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 02:32:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 11:33 Message generated for change (Comment added) made by hdima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- >Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 13:32 Message: Logged In: YES user_id=388573 New patch produce new error: ----------------------------- test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 299, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 1 test failed: test_strptime ------------------------------ Last time when I ran the test and it passed it was Python 2.3b1 (#1, Apr 28 2003, 11:09:08). ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 12:01 Message: Logged In: YES user_id=388573 Maybe it may helps: locale_time.timezone is ['UTC', 'GMT', 'UTC', ''] during testing ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 11:42 Message: Logged In: YES user_id=357491 Damn. OK, lets take Raymond's suggestion and try removing the time.tzset call. Try the new patch and let me know how it goes. Also, when was the last time you ran the test and it passed? I am trying to isolate if this is all happening because of my attempt to take time.daylight into account. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 11:25 Message: Logged In: YES user_id=388573 No, the same error remains ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 05:46 Message: Logged In: YES user_id=357491 So it wasn't what I thought it would be. But I do think I found the error. Dmitry, can you apply the patch that I attached to the report and see if it fixes the problem? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 16:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Tue Jul 1 11:03:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 03:03:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 00:33 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:03 Message: Logged In: YES user_id=357491 What is time.tzname and time.daylight set for both of you guys? ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 02:32 Message: Logged In: YES user_id=388573 New patch produce new error: ----------------------------- test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 299, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 1 test failed: test_strptime ------------------------------ Last time when I ran the test and it passed it was Python 2.3b1 (#1, Apr 28 2003, 11:09:08). ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 01:01 Message: Logged In: YES user_id=388573 Maybe it may helps: locale_time.timezone is ['UTC', 'GMT', 'UTC', ''] during testing ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 00:42 Message: Logged In: YES user_id=357491 Damn. OK, lets take Raymond's suggestion and try removing the time.tzset call. Try the new patch and let me know how it goes. Also, when was the last time you ran the test and it passed? I am trying to isolate if this is all happening because of my attempt to take time.daylight into account. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 00:25 Message: Logged In: YES user_id=388573 No, the same error remains ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 18:46 Message: Logged In: YES user_id=357491 So it wasn't what I thought it would be. But I do think I found the error. Dmitry, can you apply the patch that I attached to the report and see if it fixes the problem? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 16:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 05:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Tue Jul 1 11:09:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 03:09:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-763052 ] test_winsound, test_strptime fails in win2k Message-ID: Bugs item #763052, was opened at 2003-06-30 00:47 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Brett Cannon (bcannon) Summary: test_winsound, test_strptime fails in win2k Initial Comment: Hello, D:\apps\Python23>python -c "from test import test_winsound;test_winsound.test_ma in()" test_errors (test.test_winsound.BeepTest) ... ok test_extremes (test.test_winsound.BeepTest) ... ok test_increasingfrequency (test.test_winsound.BeepTest) ... ok test_asterisk (test.test_winsound.MessageBeepTest) ... ok test_default (test.test_winsound.MessageBeepTest) ... ok test_exclamation (test.test_winsound.MessageBeepTest) ... ok test_hand (test.test_winsound.MessageBeepTest) ... ok test_ok (test.test_winsound.MessageBeepTest) ... ok test_question (test.test_winsound.MessageBeepTest) ... ok test_alias_asterisk (test.test_winsound.PlaySoundTest) ... ok test_alias_exclamation (test.test_winsound.PlaySoundTest) ... ok test_alias_exit (test.test_winsound.PlaySoundTest) ... ok test_alias_fallback (test.test_winsound.PlaySoundTest) ... ok test_alias_hand (test.test_winsound.PlaySoundTest) ... ok test_alias_nofallback (test.test_winsound.PlaySoundTest) ... ok test_alias_question (test.test_winsound.PlaySoundTest) ... ok test_errors (test.test_winsound.PlaySoundTest) ... ok test_stopasync (test.test_winsound.PlaySoundTest) ... FAIL ====================================================================== FAIL: test_stopasync (test.test_winsound.PlaySoundTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------------------------------------------------- Ran 18 tests in 6.199s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_winsound.py", line 99, in test_main test_support.run_unittest(BeepTest, MessageBeepTest, PlaySoundTest) File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------- D:\apps\Python23>python -c "from test import test_strptime; test_strptime.test_m ain()" test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok test_by_hand_input (test.test_strptime.LocaleTime_Tests) ... ok test_date_time (test.test_strptime.LocaleTime_Tests) ... ok test_lang (test.test_strptime.LocaleTime_Tests) ... ok test_month (test.test_strptime.LocaleTime_Tests) ... ok test_timezone (test.test_strptime.LocaleTime_Tests) ... ok test_unknowntimezone (test.test_strptime.LocaleTime_Tests) ... ok test_weekday (test.test_strptime.LocaleTime_Tests) ... ok test_blankpattern (test.test_strptime.TimeRETests) ... ok test_compile (test.test_strptime.TimeRETests) ... ok test_getitem (test.test_strptime.TimeRETests) ... ok test_matching_with_escapes (test.test_strptime.TimeRETests) ... ok test_pattern (test.test_strptime.TimeRETests) ... ok test_pattern_escaping (test.test_strptime.TimeRETests) ... ok test_TypeError (test.test_strptime.StrptimeTests) ... ok test_caseinsensitive (test.test_strptime.StrptimeTests) ... ok test_date (test.test_strptime.StrptimeTests) ... ok test_date_time (test.test_strptime.StrptimeTests) ... ok test_day (test.test_strptime.StrptimeTests) ... ok test_defaults (test.test_strptime.StrptimeTests) ... ok test_hour (test.test_strptime.StrptimeTests) ... ok test_julian (test.test_strptime.StrptimeTests) ... ok test_minute (test.test_strptime.StrptimeTests) ... ok test_month (test.test_strptime.StrptimeTests) ... ok test_percent (test.test_strptime.StrptimeTests) ... ok test_second (test.test_strptime.StrptimeTests) ... ok test_time (test.test_strptime.StrptimeTests) ... ok test_timezone (test.test_strptime.StrptimeTests) ... FAIL test_unconverteddata (test.test_strptime.StrptimeTests) ... ok test_weekday (test.test_strptime.StrptimeTests) ... ok test_year (test.test_strptime.StrptimeTests) ... ok test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests) ... ok test_all_julian_days (test.test_strptime.JulianTests) ... ok test_day_of_week_calculation (test.test_strptime.CalculationTests) ... ok test_gregorian_calculation (test.test_strptime.CalculationTests) ... ok test_julian_calculation (test.test_strptime.CalculationTests) ... ok ====================================================================== FAIL: test_timezone (test.test_strptime.StrptimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- Ran 36 tests in 0.330s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_strptime.py", line 421, in test_main CalculationTests File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:09 Message: Logged In: YES user_id=357491 OK. I reponded in the other bug report asking both of you to tell me what time.tzname and time.daylight are set to. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 01:14 Message: Logged In: YES user_id=358087 Hello Brett, Sorry but no sigar (for both fixes). I'm attaching starck trace for both fixes. My time zone is GMT+2 (Jerusalem), and this is a laptop (IBM T30). Miki ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 18:49 Message: Logged In: YES user_id=357491 Miki, can you follow the test_strptime issues on bug #763047 ? It is the same problem and it will be easier to manage if you can follow along there. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 05:03 Message: Logged In: YES user_id=89016 The most likely reason for the winsound failure is, that your "SystemQuestion" sound has already finished before the second one starts, so there will be no RuntimeError exception. Checked in a fix as: Lib/test/test_winsound.py 1.6 Assigning to Brett Cannon for the strptime stuff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 From noreply@sourceforge.net Tue Jul 1 11:41:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 03:41:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 11:33 Message generated for change (Comment added) made by hdima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- >Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 14:41 Message: Logged In: YES user_id=388573 Python 2.3b2+ (#1, Jul 1 2003, 10:37:33) [GCC 2.96 20000731 (ASPLinux 7.3 2.96-112)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.tzname ('UTC', 'UTC') >>> time.daylight 0 >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 14:03 Message: Logged In: YES user_id=357491 What is time.tzname and time.daylight set for both of you guys? ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 13:32 Message: Logged In: YES user_id=388573 New patch produce new error: ----------------------------- test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 299, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 1 test failed: test_strptime ------------------------------ Last time when I ran the test and it passed it was Python 2.3b1 (#1, Apr 28 2003, 11:09:08). ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 12:01 Message: Logged In: YES user_id=388573 Maybe it may helps: locale_time.timezone is ['UTC', 'GMT', 'UTC', ''] during testing ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 11:42 Message: Logged In: YES user_id=357491 Damn. OK, lets take Raymond's suggestion and try removing the time.tzset call. Try the new patch and let me know how it goes. Also, when was the last time you ran the test and it passed? I am trying to isolate if this is all happening because of my attempt to take time.daylight into account. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 11:25 Message: Logged In: YES user_id=388573 No, the same error remains ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 05:46 Message: Logged In: YES user_id=357491 So it wasn't what I thought it would be. But I do think I found the error. Dmitry, can you apply the patch that I attached to the report and see if it fixes the problem? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 16:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Tue Jul 1 12:25:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 04:25:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-763362 ] test_posixpath failed Message-ID: Bugs item #763362, was opened at 2003-06-30 19:01 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763362&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Neal Norwitz (nnorwitz) Summary: test_posixpath failed Initial Comment: I get the following with current cvs on Tru64Unix 5.1A: test_posix test_posixpath test test_posixpath failed -- Traceback (most recent call last): File "/mnt/python/dist/src/Lib/test/test_posixpath.py", line 343, in test_expanduser posixpath.expanduser("~/") File "/mnt/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: '//' != '/' ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-07-01 13:25 Message: Logged In: YES user_id=89016 Thanks for the quick fix. Is there any better way the exercise expanduser() and check return values without any assumptions about the result that don't hold an Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 05:34 Message: Logged In: YES user_id=33168 Checked in as: Lib/test/test_posixpath.py 1.9 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763362&group_id=5470 From noreply@sourceforge.net Tue Jul 1 12:36:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 04:36:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-763052 ] test_winsound, test_strptime fails in win2k Message-ID: Bugs item #763052, was opened at 2003-06-30 10:47 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Brett Cannon (bcannon) Summary: test_winsound, test_strptime fails in win2k Initial Comment: Hello, D:\apps\Python23>python -c "from test import test_winsound;test_winsound.test_ma in()" test_errors (test.test_winsound.BeepTest) ... ok test_extremes (test.test_winsound.BeepTest) ... ok test_increasingfrequency (test.test_winsound.BeepTest) ... ok test_asterisk (test.test_winsound.MessageBeepTest) ... ok test_default (test.test_winsound.MessageBeepTest) ... ok test_exclamation (test.test_winsound.MessageBeepTest) ... ok test_hand (test.test_winsound.MessageBeepTest) ... ok test_ok (test.test_winsound.MessageBeepTest) ... ok test_question (test.test_winsound.MessageBeepTest) ... ok test_alias_asterisk (test.test_winsound.PlaySoundTest) ... ok test_alias_exclamation (test.test_winsound.PlaySoundTest) ... ok test_alias_exit (test.test_winsound.PlaySoundTest) ... ok test_alias_fallback (test.test_winsound.PlaySoundTest) ... ok test_alias_hand (test.test_winsound.PlaySoundTest) ... ok test_alias_nofallback (test.test_winsound.PlaySoundTest) ... ok test_alias_question (test.test_winsound.PlaySoundTest) ... ok test_errors (test.test_winsound.PlaySoundTest) ... ok test_stopasync (test.test_winsound.PlaySoundTest) ... FAIL ====================================================================== FAIL: test_stopasync (test.test_winsound.PlaySoundTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------------------------------------------------- Ran 18 tests in 6.199s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_winsound.py", line 99, in test_main test_support.run_unittest(BeepTest, MessageBeepTest, PlaySoundTest) File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------- D:\apps\Python23>python -c "from test import test_strptime; test_strptime.test_m ain()" test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok test_by_hand_input (test.test_strptime.LocaleTime_Tests) ... ok test_date_time (test.test_strptime.LocaleTime_Tests) ... ok test_lang (test.test_strptime.LocaleTime_Tests) ... ok test_month (test.test_strptime.LocaleTime_Tests) ... ok test_timezone (test.test_strptime.LocaleTime_Tests) ... ok test_unknowntimezone (test.test_strptime.LocaleTime_Tests) ... ok test_weekday (test.test_strptime.LocaleTime_Tests) ... ok test_blankpattern (test.test_strptime.TimeRETests) ... ok test_compile (test.test_strptime.TimeRETests) ... ok test_getitem (test.test_strptime.TimeRETests) ... ok test_matching_with_escapes (test.test_strptime.TimeRETests) ... ok test_pattern (test.test_strptime.TimeRETests) ... ok test_pattern_escaping (test.test_strptime.TimeRETests) ... ok test_TypeError (test.test_strptime.StrptimeTests) ... ok test_caseinsensitive (test.test_strptime.StrptimeTests) ... ok test_date (test.test_strptime.StrptimeTests) ... ok test_date_time (test.test_strptime.StrptimeTests) ... ok test_day (test.test_strptime.StrptimeTests) ... ok test_defaults (test.test_strptime.StrptimeTests) ... ok test_hour (test.test_strptime.StrptimeTests) ... ok test_julian (test.test_strptime.StrptimeTests) ... ok test_minute (test.test_strptime.StrptimeTests) ... ok test_month (test.test_strptime.StrptimeTests) ... ok test_percent (test.test_strptime.StrptimeTests) ... ok test_second (test.test_strptime.StrptimeTests) ... ok test_time (test.test_strptime.StrptimeTests) ... ok test_timezone (test.test_strptime.StrptimeTests) ... FAIL test_unconverteddata (test.test_strptime.StrptimeTests) ... ok test_weekday (test.test_strptime.StrptimeTests) ... ok test_year (test.test_strptime.StrptimeTests) ... ok test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests) ... ok test_all_julian_days (test.test_strptime.JulianTests) ... ok test_day_of_week_calculation (test.test_strptime.CalculationTests) ... ok test_gregorian_calculation (test.test_strptime.CalculationTests) ... ok test_julian_calculation (test.test_strptime.CalculationTests) ... ok ====================================================================== FAIL: test_timezone (test.test_strptime.StrptimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- Ran 36 tests in 0.330s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_strptime.py", line 421, in test_main CalculationTests File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 14:36 Message: Logged In: YES user_id=358087 Hello Brett, >>> import time >>> time.tzname ('Jerusalem Standard Time', 'Jerusalem Standard Time') >>> time.daylight 0 >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:09 Message: Logged In: YES user_id=357491 OK. I reponded in the other bug report asking both of you to tell me what time.tzname and time.daylight are set to. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 11:14 Message: Logged In: YES user_id=358087 Hello Brett, Sorry but no sigar (for both fixes). I'm attaching starck trace for both fixes. My time zone is GMT+2 (Jerusalem), and this is a laptop (IBM T30). Miki ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 04:49 Message: Logged In: YES user_id=357491 Miki, can you follow the test_strptime issues on bug #763047 ? It is the same problem and it will be easier to manage if you can follow along there. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 15:03 Message: Logged In: YES user_id=89016 The most likely reason for the winsound failure is, that your "SystemQuestion" sound has already finished before the second one starts, so there will be no RuntimeError exception. Checked in a fix as: Lib/test/test_winsound.py 1.6 Assigning to Brett Cannon for the strptime stuff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 From noreply@sourceforge.net Tue Jul 1 12:47:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 04:47:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-763708 ] Failures in test_macostools Message-ID: Bugs item #763708, was opened at 2003-07-01 08:54 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 13:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply@sourceforge.net Tue Jul 1 13:37:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 05:37:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-748926 ] broken ncurses support in current cvs and last distribution Message-ID: Bugs item #748926, was opened at 2003-06-04 17:23 Message generated for change (Settings changed) made by mmokrejs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) >Summary: broken ncurses support in current cvs and last distribution Initial Comment: I found configure looks for ncurses.h instead of ncurses/ncurses.h. Please note that newer version of ncurses have moved ncurses.h to a subdirectory ncurses/. Even after fixing configure and Modules/_curses_panel.c, I get: cc: Error: /software/@sys/usr/include/ncurses/curses.h, line 506: Missing identifier. (parnoident) extern NCURSES_EXPORT(int) addch (const chtype); /* generated */ ---------------------------^ cc: Error: /software/@sys/usr/include/ncurses/curses.h, line 507: Missing identifier. (parnoident) extern NCURSES_EXPORT(int) addchnstr (const chtype *, int); /* generated */ ---------------------------^ cc: Error: /software/@sys/usr/include/ncurses/curses.h, line 508: Missing identifier. (parnoident) extern NCURSES_EXPORT(int) addchstr (const chtype *); /* generated */ ---------------------------^ Any ideas? ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-30 19:24 Message: Logged In: YES user_id=696559 Hi, so the problem is that I have to manually specify -I/software/@sys/usr/include -I/software/@sys/usr/include/ncurses under BASECFLAGS in src/Makefile. If I set these includes on CPPFLAGS, they're used only for building the python core, not the modules. I believe the configure should test for both: ncurses-5.3 and newer install into $prefix/include/ncurses/ instead of former $prefix/include/. This change should be reflected by the configure script. I believe the dist/src/Modules/_curses_panel.c calling panel.h should be adjusted properly. It is not a must as long as configure will set -I$pref/include -I$pref/include/ncurses. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-17 23:37 Message: Logged In: YES user_id=696559 Second reply(I have to add I'll retry once more, but I believe the whole story is python used to compile fine with older ncurses, which placed headers into include/ . Newer versions place headers into include/ncurses/ subdirectory, and that is not expected. I do not have the gcc problem with gcc fixincludes as the machine was recently installed and there were always ncurses 5.0 and above installed.): > Hi Thomas, > but I use cc from DEC?DIGITAL/COMPAQ/HP, so it shouldn't see those > "fixed" headers, right? no - gcc is the one that "fixes" headers. It is unlikely that your $CFLAGS or $CPPFLAGS has an explicit -I/usr/lib/gcc-lib/i386-linux/3.0.4/include Then it sounds like a variation of the other sort of problem: compiler finds one of the headers, but not all. The message seems to indicate that the compiler did not find a definition for NCURSES_EXPORT, which is defined in ncurses_dll.h What I'd look for: since most applications do not distinguish #include and #include by ifdef's is that your options have only -I/software/@sys/usr/include/ncurses rather than -I/software/@sys/usr/include -I/software/@sys/usr/include/ncurses Since the ncurses headers (unctrl.h, term.h) will have a line like #include it really needs both -I options. (Specifying both still does not work around the gcc fixincludes problem - that's why I remember that one first). > > (It's "fixing" a place which is providing a typedef if it doesn't exist). > > I modified the ifdef's to avoid this problem. The quick fix is to remove > > curses.h from gcc's fixed-includes. The reason why NCURSES_EXPORT is not > > defined is because gcc finds the wrong curses.h and doesn't find ncurses_dll.h > > because its fixed-include forces it into the wrong search path. > > > > If it's not that - perhaps more info. (Perhaps just setting $CPPFLAGS in > > the environment is needed). > > But the message > > cc: Error: /software/@sys/usr/include/ncurses/curses.h, > line 506: Missing identifier. (parnoident) > extern NCURSES_EXPORT(int) addch (const chtype); > /* generated */ > ---------------------------^ > cc: Error: /software/@sys/usr/include/ncurses/curses.h, > line 507: Missing identifier. (parnoident) > extern NCURSES_EXPORT(int) addchnstr (const chtype *, > int); /* generated */ > ---------------------------^ > cc: Error: /software/@sys/usr/include/ncurses/curses.h, > line 508: Missing identifier. (parnoident) > extern NCURSES_EXPORT(int) addchstr (const chtype *); > /* generated */ > ---------------------------^ > > confirms that CPPFLAGS or CFLAGS point to the location where ncurses are > installed! Maybe the problem is that ncurses/ncurses.h are stored as > ncurses/curses.h? > ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-17 22:35 Message: Logged In: YES user_id=21627 I see. This seems to be either a bug in ncurses, or in gcc. Closing as third-party. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-17 16:10 Message: Logged In: YES user_id=696559 I asked the developer of ncurses. This is his first reply. From: Thomas Dickey My guess (because I've seen it a few times) is that it's a system where someone installed a new version of gcc. Its fixincludes script was modified a year or two ago with the effect of putting a copy of curses.h into gcc's so-called fixed-include files, e.g., /usr/lib/gcc-lib/i386-linux/3.0.4/include (It's "fixing" a place which is providing a typedef if it doesn't exist). I modified the ifdef's to avoid this problem. The quick fix is to remove curses.h from gcc's fixed-includes. The reason why NCURSES_EXPORT is not defined is because gcc finds the wrong curses.h and doesn't find ncurses_dll.h because its fixed-include forces it into the wrong search path. If it's not that - perhaps more info. (Perhaps just setting $CPPFLAGS in the environment is needed). ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-17 15:00 Message: Logged In: YES user_id=696559 Sorry, I'm not aprogrammer, should I attach some of the headers files distributed by ncurses? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 08:50 Message: Logged In: YES user_id=21627 Can you report how NCURSES_EXPORT is defined on your system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470 From noreply@sourceforge.net Tue Jul 1 13:43:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 05:43:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-753592 ] websucker bug Message-ID: Bugs item #753592, was opened at 2003-06-12 18:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753592&group_id=5470 Category: Demos and Tools >Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Dalke (dalke) >Assigned to: Neal Norwitz (nnorwitz) Summary: websucker bug Initial Comment: from c.l.py poster Anton Vredegoor who doesn't like that SF has a "must login to post bugs" barrier, and whose IE has problems handling the SF bugs page. On Win98Se, Python23: > >>d:\python23\pythonw -u wsgui.py >Exception in Tkinter callback >Traceback (most recent call last): > File "D:\PYTHON23\lib\lib-tk\Tkinter.py", line 1337, in __call__ > return self.func(*args) > File "wsgui.py", line 163, in go > self.sucker.rootdir = os.path.dirname( >TypeError: unbound method savefilename() must be called with Sucker >instance as first argument (got App instance instead) >>Exit code: 0 My bug-fix: change only 1 line (164): websucker.Sucker.savefilename(self, url)) into: websucker.Sucker.savefilename(self.sucker, url)) I've tested it and now it works as expected. Can we get this in Python23 final? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 08:43 Message: Logged In: YES user_id=33168 I guess since it didn't work. :-) I thought I tested that. Oh well. Your fix seems to work. Checked in as Tools/webchecker/wsgui.py 1.7 and 1.5.18.1 Thanks. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-12 21:14 Message: Logged In: YES user_id=33168 Why wouldn't you want to do self.sucker.savefilename(url)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=753592&group_id=5470 From noreply@sourceforge.net Tue Jul 1 14:44:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 06:44:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-763770 ] test_socket_ssl crash Message-ID: Bugs item #763770, was opened at 2003-07-01 05:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763770&group_id=5470 Category: Demos and Tools Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) >Assigned to: Neal Norwitz (nnorwitz) Summary: test_socket_ssl crash Initial Comment: test_socket test_socket_ssl test test_socket_ssl crashed -- exceptions.AttributeError: 'module' object has no attribute 'sslerror' test_socketserver test_socketserver skipped -- Use of the `network' resource not enabled test_softspace I used current cvs checkout on Tru64Unix 5.1A, cc compiled binaries. Do you need more info? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 09:44 Message: Logged In: YES user_id=33168 Checked in as: Lib/test/test_socket_ssl.py 1.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763770&group_id=5470 From noreply@sourceforge.net Tue Jul 1 13:59:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 05:59:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-763362 ] test_posixpath failed Message-ID: Bugs item #763362, was opened at 2003-06-30 13:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763362&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Neal Norwitz (nnorwitz) Summary: test_posixpath failed Initial Comment: I get the following with current cvs on Tru64Unix 5.1A: test_posix test_posixpath test test_posixpath failed -- Traceback (most recent call last): File "/mnt/python/dist/src/Lib/test/test_posixpath.py", line 343, in test_expanduser posixpath.expanduser("~/") File "/mnt/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: '//' != '/' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 08:59 Message: Logged In: YES user_id=33168 You could try to test different permutations of: * HOME set/not set * HOMEPATH set/not set (for windows) * path contains / or no / * path ends with / or no / It's hard, perhaps impossible, to get all these to work on both Windows and Unix though. I don't have any good ideas. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-01 07:25 Message: Logged In: YES user_id=89016 Thanks for the quick fix. Is there any better way the exercise expanduser() and check return values without any assumptions about the result that don't hold an Windows? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 23:34 Message: Logged In: YES user_id=33168 Checked in as: Lib/test/test_posixpath.py 1.9 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763362&group_id=5470 From noreply@sourceforge.net Tue Jul 1 14:44:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 06:44:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-763032 ] tut/contents.html does not exist Message-ID: Bugs item #763032, was opened at 2003-06-30 02:59 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Pending Resolution: Fixed >Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: tut/contents.html does not exist Initial Comment: 2.2.3 and 2.3: generating the html tutorial doesn't create tut/contents.html, although it's referenced by other tut/* pages. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-01 09:44 Message: Logged In: YES user_id=3066 I don't see this. Can you tell me exactly which file you downloaded? The full filename and where you found it would both help. Also, the name of a file that contains the bogus link. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-30 18:01 Message: Logged In: YES user_id=3066 Re-opened so I won't forget to look at this later; hopefully tonight. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-06-30 17:09 Message: Logged In: YES user_id=60903 I'm confused. This is what I got from the 2.3b2 tarball ... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-30 13:13 Message: Logged In: YES user_id=3066 This was fixed in time for the Python 2.3 beta 2 release; please update your copy of the formatting tools. In particular, Doc/perl/l2hinit.perl needs to be updated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470 From noreply@sourceforge.net Tue Jul 1 15:18:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 07:18:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-763052 ] test_winsound, test_strptime fails in win2k Message-ID: Bugs item #763052, was opened at 2003-06-30 07:47 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Brett Cannon (bcannon) Summary: test_winsound, test_strptime fails in win2k Initial Comment: Hello, D:\apps\Python23>python -c "from test import test_winsound;test_winsound.test_ma in()" test_errors (test.test_winsound.BeepTest) ... ok test_extremes (test.test_winsound.BeepTest) ... ok test_increasingfrequency (test.test_winsound.BeepTest) ... ok test_asterisk (test.test_winsound.MessageBeepTest) ... ok test_default (test.test_winsound.MessageBeepTest) ... ok test_exclamation (test.test_winsound.MessageBeepTest) ... ok test_hand (test.test_winsound.MessageBeepTest) ... ok test_ok (test.test_winsound.MessageBeepTest) ... ok test_question (test.test_winsound.MessageBeepTest) ... ok test_alias_asterisk (test.test_winsound.PlaySoundTest) ... ok test_alias_exclamation (test.test_winsound.PlaySoundTest) ... ok test_alias_exit (test.test_winsound.PlaySoundTest) ... ok test_alias_fallback (test.test_winsound.PlaySoundTest) ... ok test_alias_hand (test.test_winsound.PlaySoundTest) ... ok test_alias_nofallback (test.test_winsound.PlaySoundTest) ... ok test_alias_question (test.test_winsound.PlaySoundTest) ... ok test_errors (test.test_winsound.PlaySoundTest) ... ok test_stopasync (test.test_winsound.PlaySoundTest) ... FAIL ====================================================================== FAIL: test_stopasync (test.test_winsound.PlaySoundTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------------------------------------------------- Ran 18 tests in 6.199s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_winsound.py", line 99, in test_main test_support.run_unittest(BeepTest, MessageBeepTest, PlaySoundTest) File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------- D:\apps\Python23>python -c "from test import test_strptime; test_strptime.test_m ain()" test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok test_by_hand_input (test.test_strptime.LocaleTime_Tests) ... ok test_date_time (test.test_strptime.LocaleTime_Tests) ... ok test_lang (test.test_strptime.LocaleTime_Tests) ... ok test_month (test.test_strptime.LocaleTime_Tests) ... ok test_timezone (test.test_strptime.LocaleTime_Tests) ... ok test_unknowntimezone (test.test_strptime.LocaleTime_Tests) ... ok test_weekday (test.test_strptime.LocaleTime_Tests) ... ok test_blankpattern (test.test_strptime.TimeRETests) ... ok test_compile (test.test_strptime.TimeRETests) ... ok test_getitem (test.test_strptime.TimeRETests) ... ok test_matching_with_escapes (test.test_strptime.TimeRETests) ... ok test_pattern (test.test_strptime.TimeRETests) ... ok test_pattern_escaping (test.test_strptime.TimeRETests) ... ok test_TypeError (test.test_strptime.StrptimeTests) ... ok test_caseinsensitive (test.test_strptime.StrptimeTests) ... ok test_date (test.test_strptime.StrptimeTests) ... ok test_date_time (test.test_strptime.StrptimeTests) ... ok test_day (test.test_strptime.StrptimeTests) ... ok test_defaults (test.test_strptime.StrptimeTests) ... ok test_hour (test.test_strptime.StrptimeTests) ... ok test_julian (test.test_strptime.StrptimeTests) ... ok test_minute (test.test_strptime.StrptimeTests) ... ok test_month (test.test_strptime.StrptimeTests) ... ok test_percent (test.test_strptime.StrptimeTests) ... ok test_second (test.test_strptime.StrptimeTests) ... ok test_time (test.test_strptime.StrptimeTests) ... ok test_timezone (test.test_strptime.StrptimeTests) ... FAIL test_unconverteddata (test.test_strptime.StrptimeTests) ... ok test_weekday (test.test_strptime.StrptimeTests) ... ok test_year (test.test_strptime.StrptimeTests) ... ok test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests) ... ok test_all_julian_days (test.test_strptime.JulianTests) ... ok test_day_of_week_calculation (test.test_strptime.CalculationTests) ... ok test_gregorian_calculation (test.test_strptime.CalculationTests) ... ok test_julian_calculation (test.test_strptime.CalculationTests) ... ok ====================================================================== FAIL: test_timezone (test.test_strptime.StrptimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- Ran 36 tests in 0.330s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_strptime.py", line 421, in test_main CalculationTests File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-07-01 14:18 Message: Logged In: YES user_id=35752 I get the same error (if I remember correctly) on W2K if I set the timezone to Eastern and disable the daylight saving time correction check box. I think this sets the TZ to EST (instead of the usual EDT). ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 11:36 Message: Logged In: YES user_id=358087 Hello Brett, >>> import time >>> time.tzname ('Jerusalem Standard Time', 'Jerusalem Standard Time') >>> time.daylight 0 >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 10:09 Message: Logged In: YES user_id=357491 OK. I reponded in the other bug report asking both of you to tell me what time.tzname and time.daylight are set to. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 08:14 Message: Logged In: YES user_id=358087 Hello Brett, Sorry but no sigar (for both fixes). I'm attaching starck trace for both fixes. My time zone is GMT+2 (Jerusalem), and this is a laptop (IBM T30). Miki ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 01:49 Message: Logged In: YES user_id=357491 Miki, can you follow the test_strptime issues on bug #763047 ? It is the same problem and it will be easier to manage if you can follow along there. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 12:03 Message: Logged In: YES user_id=89016 The most likely reason for the winsound failure is, that your "SystemQuestion" sound has already finished before the second one starts, so there will be no RuntimeError exception. Checked in a fix as: Lib/test/test_winsound.py 1.6 Assigning to Brett Cannon for the strptime stuff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 From noreply@sourceforge.net Tue Jul 1 15:25:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 07:25:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-763928 ] test_bsddb3 crashes if run after test_locale Message-ID: Bugs item #763928, was opened at 2003-07-01 14:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763928&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 6 Submitted By: Neil Schemenauer (nascheme) Assigned to: Martin v. Löwis (loewis) Summary: test_bsddb3 crashes if run after test_locale Initial Comment: I found this while testing for the 2.3b2 release. This crashes on both W2K and Linux: ./python Lib/test/regrtest.py -u bsddb test_logging test_bsddb3 Only the 'locale.setlocale(locale.LC_ALL, '')' line of test_logging is necessary to trigger the bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763928&group_id=5470 From noreply@sourceforge.net Tue Jul 1 16:00:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 08:00:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-763023 ] difflib.py: line 528 in ratio() zero division not caught Message-ID: Bugs item #763023, was opened at 2003-06-30 02:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470 Category: Python Library Group: Python 2.2.3 >Status: Closed Resolution: Accepted Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Neal Norwitz (nnorwitz) Summary: difflib.py: line 528 in ratio() zero division not caught Initial Comment: 2.2.3 and 2.3b1: >>> from difflib import * >>> s = SequenceMatcher(None, [], []) >>> s.ratio() Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.2/difflib.py", line 528, in ratio return 2.0 * matches / (len(self.a) + len(self.b)) ZeroDivisionError: float division ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 11:00 Message: Logged In: YES user_id=33168 Checked in as: * Lib/difflib.py 1.15 * Lib/test/test_difflib.py 1.6 * Misc/NEWS 1.805 Fix still needs to be backported. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 00:40 Message: Logged In: YES user_id=80475 Looks good. See attached test to replace the existing testfile. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 23:37 Message: Logged In: YES user_id=33168 There should be a test for this too, but I'm not real familiar with doctest. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 23:36 Message: Logged In: YES user_id=33168 How about we split the difference, say 0.5. :-) Raymond (or Tim) could you review the attached patch? Ok adding this new (non-public) function? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-30 18:29 Message: Logged In: YES user_id=31435 Heh. How a ZeroDivisionError coming out of a method named *ratio* can be a surprise is beyond me . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 11:34 Message: Logged In: YES user_id=80475 One other thought. The same fix should be made to all three ratio methods (including quick and real-quick). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 11:30 Message: Logged In: YES user_id=80475 When the denominator is zero, it means that both sequences are of zero-length; therefore, the two sequences are equal, so the return value should be 1.0. The try / except ZeroDivision error approach look good. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 11:19 Message: Logged In: YES user_id=33168 This affects 2.3 as well (line 614). The return line can be wrapped with try/except ZeroDivisionError. Raymond, should 0.0 be returned in this case? Should something else be done? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763023&group_id=5470 From noreply@sourceforge.net Tue Jul 1 16:18:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 08:18:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-764003 ] super() does not work as documented Message-ID: Bugs item #764003, was opened at 2003-07-01 17:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764003&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: super() does not work as documented Initial Comment: According to the docs, I can use class names as type object, but that does not work. Strange enough, this is used in the python core modules (ie random.py): > python2.3 Python 2.3b2 (#2, Jun 30 2003, 10:50:53) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class a: ... def f (self): ... print 1 ... >>> class b(a): ... def f (self): ... super(b, self).f() ... print 2 ... >>> b().f() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in f TypeError: super() argument 1 must be type, not classobj ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764003&group_id=5470 From noreply@sourceforge.net Tue Jul 1 17:20:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 09:20:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-764003 ] super() does not work as documented Message-ID: Bugs item #764003, was opened at 2003-07-01 17:18 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764003&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: super() does not work as documented Initial Comment: According to the docs, I can use class names as type object, but that does not work. Strange enough, this is used in the python core modules (ie random.py): > python2.3 Python 2.3b2 (#2, Jun 30 2003, 10:50:53) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class a: ... def f (self): ... print 1 ... >>> class b(a): ... def f (self): ... super(b, self).f() ... print 2 ... >>> b().f() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in f TypeError: super() argument 1 must be type, not classobj ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-07-01 18:20 Message: Logged In: YES user_id=89016 super() only works for new style classes. This doesn't seem to be documented: neither in http://www.python.org/dev/doc/devel/lib/built-in-funcs.html nor in super.__doc__. Assigning to Fred. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764003&group_id=5470 From noreply@sourceforge.net Tue Jul 1 17:47:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 09:47:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-764049 ] pythonw crashes under one windows platform (easy-everything) Message-ID: Bugs item #764049, was opened at 2003-07-01 16: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=764049&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Angel Perea Martinez (angelpeream) Assigned to: Tim Peters (tim_one) Summary: pythonw crashes under one windows platform (easy-everything) Initial Comment: pythonw (Python 2.3b2 (#43, Jun 29 2003, 16:43:04)) crashes (performs an invalid operation) under some special windows platform (easy-everything internet-cafe PCs). Previous versions showed no problem. Not surely a bug, but disencourages trying the language. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764049&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:15:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:15:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-748926 ] broken ncurses support in current cvs and last distribution Message-ID: Bugs item #748926, was opened at 2003-06-04 17:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: broken ncurses support in current cvs and last distribution Initial Comment: I found configure looks for ncurses.h instead of ncurses/ncurses.h. Please note that newer version of ncurses have moved ncurses.h to a subdirectory ncurses/. Even after fixing configure and Modules/_curses_panel.c, I get: cc: Error: /software/@sys/usr/include/ncurses/curses.h, line 506: Missing identifier. (parnoident) extern NCURSES_EXPORT(int) addch (const chtype); /* generated */ ---------------------------^ cc: Error: /software/@sys/usr/include/ncurses/curses.h, line 507: Missing identifier. (parnoident) extern NCURSES_EXPORT(int) addchnstr (const chtype *, int); /* generated */ ---------------------------^ cc: Error: /software/@sys/usr/include/ncurses/curses.h, line 508: Missing identifier. (parnoident) extern NCURSES_EXPORT(int) addchstr (const chtype *); /* generated */ ---------------------------^ Any ideas? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-01 19:15 Message: Logged In: YES user_id=21627 Well, that is not the problem you have originally reported? I completely lost track what the problem is that you are reporting. If so, please close this report, and submit a new one indicating 1. What you did. 2. What happened. 3. What you expected to happen instead. 4. (optionally) why you think that happened. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-30 19:24 Message: Logged In: YES user_id=696559 Hi, so the problem is that I have to manually specify -I/software/@sys/usr/include -I/software/@sys/usr/include/ncurses under BASECFLAGS in src/Makefile. If I set these includes on CPPFLAGS, they're used only for building the python core, not the modules. I believe the configure should test for both: ncurses-5.3 and newer install into $prefix/include/ncurses/ instead of former $prefix/include/. This change should be reflected by the configure script. I believe the dist/src/Modules/_curses_panel.c calling panel.h should be adjusted properly. It is not a must as long as configure will set -I$pref/include -I$pref/include/ncurses. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-17 23:37 Message: Logged In: YES user_id=696559 Second reply(I have to add I'll retry once more, but I believe the whole story is python used to compile fine with older ncurses, which placed headers into include/ . Newer versions place headers into include/ncurses/ subdirectory, and that is not expected. I do not have the gcc problem with gcc fixincludes as the machine was recently installed and there were always ncurses 5.0 and above installed.): > Hi Thomas, > but I use cc from DEC?DIGITAL/COMPAQ/HP, so it shouldn't see those > "fixed" headers, right? no - gcc is the one that "fixes" headers. It is unlikely that your $CFLAGS or $CPPFLAGS has an explicit -I/usr/lib/gcc-lib/i386-linux/3.0.4/include Then it sounds like a variation of the other sort of problem: compiler finds one of the headers, but not all. The message seems to indicate that the compiler did not find a definition for NCURSES_EXPORT, which is defined in ncurses_dll.h What I'd look for: since most applications do not distinguish #include and #include by ifdef's is that your options have only -I/software/@sys/usr/include/ncurses rather than -I/software/@sys/usr/include -I/software/@sys/usr/include/ncurses Since the ncurses headers (unctrl.h, term.h) will have a line like #include it really needs both -I options. (Specifying both still does not work around the gcc fixincludes problem - that's why I remember that one first). > > (It's "fixing" a place which is providing a typedef if it doesn't exist). > > I modified the ifdef's to avoid this problem. The quick fix is to remove > > curses.h from gcc's fixed-includes. The reason why NCURSES_EXPORT is not > > defined is because gcc finds the wrong curses.h and doesn't find ncurses_dll.h > > because its fixed-include forces it into the wrong search path. > > > > If it's not that - perhaps more info. (Perhaps just setting $CPPFLAGS in > > the environment is needed). > > But the message > > cc: Error: /software/@sys/usr/include/ncurses/curses.h, > line 506: Missing identifier. (parnoident) > extern NCURSES_EXPORT(int) addch (const chtype); > /* generated */ > ---------------------------^ > cc: Error: /software/@sys/usr/include/ncurses/curses.h, > line 507: Missing identifier. (parnoident) > extern NCURSES_EXPORT(int) addchnstr (const chtype *, > int); /* generated */ > ---------------------------^ > cc: Error: /software/@sys/usr/include/ncurses/curses.h, > line 508: Missing identifier. (parnoident) > extern NCURSES_EXPORT(int) addchstr (const chtype *); > /* generated */ > ---------------------------^ > > confirms that CPPFLAGS or CFLAGS point to the location where ncurses are > installed! Maybe the problem is that ncurses/ncurses.h are stored as > ncurses/curses.h? > ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-17 22:35 Message: Logged In: YES user_id=21627 I see. This seems to be either a bug in ncurses, or in gcc. Closing as third-party. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-17 16:10 Message: Logged In: YES user_id=696559 I asked the developer of ncurses. This is his first reply. From: Thomas Dickey My guess (because I've seen it a few times) is that it's a system where someone installed a new version of gcc. Its fixincludes script was modified a year or two ago with the effect of putting a copy of curses.h into gcc's so-called fixed-include files, e.g., /usr/lib/gcc-lib/i386-linux/3.0.4/include (It's "fixing" a place which is providing a typedef if it doesn't exist). I modified the ifdef's to avoid this problem. The quick fix is to remove curses.h from gcc's fixed-includes. The reason why NCURSES_EXPORT is not defined is because gcc finds the wrong curses.h and doesn't find ncurses_dll.h because its fixed-include forces it into the wrong search path. If it's not that - perhaps more info. (Perhaps just setting $CPPFLAGS in the environment is needed). ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-17 15:00 Message: Logged In: YES user_id=696559 Sorry, I'm not aprogrammer, should I attach some of the headers files distributed by ncurses? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 08:50 Message: Logged In: YES user_id=21627 Can you report how NCURSES_EXPORT is defined on your system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:19:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:19:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-748926 ] broken ncurses support in current cvs and last distribution Message-ID: Bugs item #748926, was opened at 2003-06-04 17:23 Message generated for change (Settings changed) made by mmokrejs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470 Category: None Group: Python 2.3 >Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: broken ncurses support in current cvs and last distribution Initial Comment: I found configure looks for ncurses.h instead of ncurses/ncurses.h. Please note that newer version of ncurses have moved ncurses.h to a subdirectory ncurses/. Even after fixing configure and Modules/_curses_panel.c, I get: cc: Error: /software/@sys/usr/include/ncurses/curses.h, line 506: Missing identifier. (parnoident) extern NCURSES_EXPORT(int) addch (const chtype); /* generated */ ---------------------------^ cc: Error: /software/@sys/usr/include/ncurses/curses.h, line 507: Missing identifier. (parnoident) extern NCURSES_EXPORT(int) addchnstr (const chtype *, int); /* generated */ ---------------------------^ cc: Error: /software/@sys/usr/include/ncurses/curses.h, line 508: Missing identifier. (parnoident) extern NCURSES_EXPORT(int) addchstr (const chtype *); /* generated */ ---------------------------^ Any ideas? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-01 19:15 Message: Logged In: YES user_id=21627 Well, that is not the problem you have originally reported? I completely lost track what the problem is that you are reporting. If so, please close this report, and submit a new one indicating 1. What you did. 2. What happened. 3. What you expected to happen instead. 4. (optionally) why you think that happened. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-30 19:24 Message: Logged In: YES user_id=696559 Hi, so the problem is that I have to manually specify -I/software/@sys/usr/include -I/software/@sys/usr/include/ncurses under BASECFLAGS in src/Makefile. If I set these includes on CPPFLAGS, they're used only for building the python core, not the modules. I believe the configure should test for both: ncurses-5.3 and newer install into $prefix/include/ncurses/ instead of former $prefix/include/. This change should be reflected by the configure script. I believe the dist/src/Modules/_curses_panel.c calling panel.h should be adjusted properly. It is not a must as long as configure will set -I$pref/include -I$pref/include/ncurses. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-17 23:37 Message: Logged In: YES user_id=696559 Second reply(I have to add I'll retry once more, but I believe the whole story is python used to compile fine with older ncurses, which placed headers into include/ . Newer versions place headers into include/ncurses/ subdirectory, and that is not expected. I do not have the gcc problem with gcc fixincludes as the machine was recently installed and there were always ncurses 5.0 and above installed.): > Hi Thomas, > but I use cc from DEC?DIGITAL/COMPAQ/HP, so it shouldn't see those > "fixed" headers, right? no - gcc is the one that "fixes" headers. It is unlikely that your $CFLAGS or $CPPFLAGS has an explicit -I/usr/lib/gcc-lib/i386-linux/3.0.4/include Then it sounds like a variation of the other sort of problem: compiler finds one of the headers, but not all. The message seems to indicate that the compiler did not find a definition for NCURSES_EXPORT, which is defined in ncurses_dll.h What I'd look for: since most applications do not distinguish #include and #include by ifdef's is that your options have only -I/software/@sys/usr/include/ncurses rather than -I/software/@sys/usr/include -I/software/@sys/usr/include/ncurses Since the ncurses headers (unctrl.h, term.h) will have a line like #include it really needs both -I options. (Specifying both still does not work around the gcc fixincludes problem - that's why I remember that one first). > > (It's "fixing" a place which is providing a typedef if it doesn't exist). > > I modified the ifdef's to avoid this problem. The quick fix is to remove > > curses.h from gcc's fixed-includes. The reason why NCURSES_EXPORT is not > > defined is because gcc finds the wrong curses.h and doesn't find ncurses_dll.h > > because its fixed-include forces it into the wrong search path. > > > > If it's not that - perhaps more info. (Perhaps just setting $CPPFLAGS in > > the environment is needed). > > But the message > > cc: Error: /software/@sys/usr/include/ncurses/curses.h, > line 506: Missing identifier. (parnoident) > extern NCURSES_EXPORT(int) addch (const chtype); > /* generated */ > ---------------------------^ > cc: Error: /software/@sys/usr/include/ncurses/curses.h, > line 507: Missing identifier. (parnoident) > extern NCURSES_EXPORT(int) addchnstr (const chtype *, > int); /* generated */ > ---------------------------^ > cc: Error: /software/@sys/usr/include/ncurses/curses.h, > line 508: Missing identifier. (parnoident) > extern NCURSES_EXPORT(int) addchstr (const chtype *); > /* generated */ > ---------------------------^ > > confirms that CPPFLAGS or CFLAGS point to the location where ncurses are > installed! Maybe the problem is that ncurses/ncurses.h are stored as > ncurses/curses.h? > ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-17 22:35 Message: Logged In: YES user_id=21627 I see. This seems to be either a bug in ncurses, or in gcc. Closing as third-party. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-17 16:10 Message: Logged In: YES user_id=696559 I asked the developer of ncurses. This is his first reply. From: Thomas Dickey My guess (because I've seen it a few times) is that it's a system where someone installed a new version of gcc. Its fixincludes script was modified a year or two ago with the effect of putting a copy of curses.h into gcc's so-called fixed-include files, e.g., /usr/lib/gcc-lib/i386-linux/3.0.4/include (It's "fixing" a place which is providing a typedef if it doesn't exist). I modified the ifdef's to avoid this problem. The quick fix is to remove curses.h from gcc's fixed-includes. The reason why NCURSES_EXPORT is not defined is because gcc finds the wrong curses.h and doesn't find ncurses_dll.h because its fixed-include forces it into the wrong search path. If it's not that - perhaps more info. (Perhaps just setting $CPPFLAGS in the environment is needed). ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-06-17 15:00 Message: Logged In: YES user_id=696559 Sorry, I'm not aprogrammer, should I attach some of the headers files distributed by ncurses? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 08:50 Message: Logged In: YES user_id=21627 Can you report how NCURSES_EXPORT is defined on your system? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=748926&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:19:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:19:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-764049 ] pythonw crashes under one windows platform (easy-everything) Message-ID: Bugs item #764049, was opened at 2003-07-01 12:47 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764049&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Angel Perea Martinez (angelpeream) >Assigned to: Nobody/Anonymous (nobody) Summary: pythonw crashes under one windows platform (easy-everything) Initial Comment: pythonw (Python 2.3b2 (#43, Jun 29 2003, 16:43:04)) crashes (performs an invalid operation) under some special windows platform (easy-everything internet-cafe PCs). Previous versions showed no problem. Not surely a bug, but disencourages trying the language. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-01 13:19 Message: Logged In: YES user_id=31435 Unassigned. If someone with access to such a platform doesn't dig into this, it appears hopeless. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764049&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:22:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:22:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-764095 ] recent test_httplib change uses network Message-ID: Bugs item #764095, was opened at 2003-07-01 11: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=764095&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Nobody/Anonymous (nobody) Summary: recent test_httplib change uses network Initial Comment: The 1.11 revision of test_httplib.py accesses www.python.org. The simplest fix is simply to add requires('network'), but the right fix imho is to mock the connection properly. I don't have a patch yet. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764095&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:22:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:22:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-762198 ] bug in signal.signal -- raises SystemError Message-ID: Bugs item #762198, was opened at 2003-06-28 00:04 Message generated for change (Comment added) made by paryl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jim McCoy (mccoy) Assigned to: Nobody/Anonymous (nobody) Summary: bug in signal.signal -- raises SystemError Initial Comment: Summary pretty much says it all. Using Py2.2.3, win2k (sp4), and twisted 1.0.5 and the call that is triggering the error is as follows: signal.signal(signal.SIGINT, self.sigInt) returns "SystemError: error return without exception set" The twisted gang has tracked it down to a C error of some sort here... ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-01 17:22 Message: Logged In: YES user_id=813621 I can reproduce the problem without importing twisted... Win2k/Python 2.2.2/wxPython 2.4.1.2 >> from signal import * >> signal(SIGINT, lambda *a: None) does not give the error. >> from signal import * >> from wxPython.wx import * >> signal(SIGINT, lambda *a: None) gives the error. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 16:06 Message: Logged In: YES user_id=6380 I don't have Win2K, but on Win98 I can't reproduce it. The bug report is pretty incomplete -- the call doesn't seem to need Twisted, so what I tried was this: >>> from signal import * >>> signal(SIGINT, lambda *a: None) This returns the previous handler as it should. So please, send more precise data about the problem, or be ignored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:24:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:24:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-763770 ] test_socket_ssl crash Message-ID: Bugs item #763770, was opened at 2003-07-01 11:24 Message generated for change (Comment added) made by mmokrejs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763770&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Neal Norwitz (nnorwitz) Summary: test_socket_ssl crash Initial Comment: test_socket test_socket_ssl test test_socket_ssl crashed -- exceptions.AttributeError: 'module' object has no attribute 'sslerror' test_socketserver test_socketserver skipped -- Use of the `network' resource not enabled test_softspace I used current cvs checkout on Tru64Unix 5.1A, cc compiled binaries. Do you need more info? ---------------------------------------------------------------------- >Comment By: Martin Mokrejs (mmokrejs) Date: 2003-07-01 19:24 Message: Logged In: YES user_id=696559 Are you sure it is fixed? I retried twice to sync with cvs, and I do not see a difference: $ ./python Lib/test/test_socket_ssl.py Traceback (most recent call last): File "Lib/test/test_socket_ssl.py", line 68, in ? test_main() File "Lib/test/test_socket_ssl.py", line 64, in test_main test_rude_shutdown() File "Lib/test/test_socket_ssl.py", line 61, in test_rude_shutdown connector() File "Lib/test/test_socket_ssl.py", line 53, in connector except socket.sslerror: AttributeError: 'module' object has no attribute 'sslerror' $ md5sum Lib/test/test_socket_ssl.py 538f17649b23cb9c0f981bf4ec71f8e9 Lib/test/test_socket_ssl.py $ Could the files contain version string in comments? I am somewhat still beginner to cvs usage. :( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 15:44 Message: Logged In: YES user_id=33168 Checked in as: Lib/test/test_socket_ssl.py 1.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763770&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:25:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:25:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-762198 ] bug in signal.signal -- raises SystemError Message-ID: Bugs item #762198, was opened at 2003-06-27 20:04 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None >Priority: 1 Submitted By: Jim McCoy (mccoy) Assigned to: Nobody/Anonymous (nobody) Summary: bug in signal.signal -- raises SystemError Initial Comment: Summary pretty much says it all. Using Py2.2.3, win2k (sp4), and twisted 1.0.5 and the call that is triggering the error is as follows: signal.signal(signal.SIGINT, self.sigInt) returns "SystemError: error return without exception set" The twisted gang has tracked it down to a C error of some sort here... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-01 13:25 Message: Logged In: YES user_id=6380 OK, there's a clue. Do you know how to report bugs in wxPython? ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-01 13:22 Message: Logged In: YES user_id=813621 I can reproduce the problem without importing twisted... Win2k/Python 2.2.2/wxPython 2.4.1.2 >> from signal import * >> signal(SIGINT, lambda *a: None) does not give the error. >> from signal import * >> from wxPython.wx import * >> signal(SIGINT, lambda *a: None) gives the error. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 12:06 Message: Logged In: YES user_id=6380 I don't have Win2K, but on Win98 I can't reproduce it. The bug report is pretty incomplete -- the call doesn't seem to need Twisted, so what I tried was this: >>> from signal import * >>> signal(SIGINT, lambda *a: None) This returns the previous handler as it should. So please, send more precise data about the problem, or be ignored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:30:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:30:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-763770 ] test_socket_ssl crash Message-ID: Bugs item #763770, was opened at 2003-07-01 05:24 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763770&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Neal Norwitz (nnorwitz) Summary: test_socket_ssl crash Initial Comment: test_socket test_socket_ssl test test_socket_ssl crashed -- exceptions.AttributeError: 'module' object has no attribute 'sslerror' test_socketserver test_socketserver skipped -- Use of the `network' resource not enabled test_softspace I used current cvs checkout on Tru64Unix 5.1A, cc compiled binaries. Do you need more info? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 13:30 Message: Logged In: YES user_id=33168 I'm pretty sure it's fixed. :-) [neal@epoch 2_3]$ md5sum Lib/test/test_socket_ssl.py 2d028597f684f3429cb4226634a1bf5d Lib/test/test_socket_ssl.py I believe the problem is that SF has made changes to CVS, so anoncvs doesn't get the changes immediately. I have attached the version of the file I checked in to CVS. I believe you can apply the patch (.diff) file too. ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2003-07-01 13:24 Message: Logged In: YES user_id=696559 Are you sure it is fixed? I retried twice to sync with cvs, and I do not see a difference: $ ./python Lib/test/test_socket_ssl.py Traceback (most recent call last): File "Lib/test/test_socket_ssl.py", line 68, in ? test_main() File "Lib/test/test_socket_ssl.py", line 64, in test_main test_rude_shutdown() File "Lib/test/test_socket_ssl.py", line 61, in test_rude_shutdown connector() File "Lib/test/test_socket_ssl.py", line 53, in connector except socket.sslerror: AttributeError: 'module' object has no attribute 'sslerror' $ md5sum Lib/test/test_socket_ssl.py 538f17649b23cb9c0f981bf4ec71f8e9 Lib/test/test_socket_ssl.py $ Could the files contain version string in comments? I am somewhat still beginner to cvs usage. :( ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 09:44 Message: Logged In: YES user_id=33168 Checked in as: Lib/test/test_socket_ssl.py 1.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763770&group_id=5470 From noreply@sourceforge.net Tue Jul 1 18:31:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 10:31:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-763637 ] 2.3b2 unpack tuple of wrong size in after_cancel Message-ID: Bugs item #763637, was opened at 2003-06-30 21:28 Message generated for change (Comment added) made by mdcowles You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763637&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3b2 unpack tuple of wrong size in after_cancel Initial Comment: The new code in after_cancel in the version of Tkinter.py that ships with 2.3b2: (script, type) = self.tk.splitlist( self.tk.call('after', 'info', id)) fails because the splitlist call returns something like ('after#53',) at least when linking against the Tcl and Tk 8.4 libraries that Fink installs under Mac OS X. ---------------------------------------------------------------------- >Comment By: Matthew Cowles (mdcowles) Date: 2003-07-01 12:31 Message: Logged In: YES user_id=198518 Yes, the patch works fine. With a little more investigation, I find that with Tcl 8.4 you sometimes get back a 2-tuple and sometimes a 1-tuple. So the comment is trivially misleading. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 22:58 Message: Logged In: YES user_id=33168 Matthew can you test the attached patch to verify if it fixes the problem. This (still) works for me on Tk 8.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763637&group_id=5470 From noreply@sourceforge.net Tue Jul 1 19:45:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 11:45:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-764003 ] super() does not work as documented Message-ID: Bugs item #764003, was opened at 2003-07-01 17:18 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764003&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: super() does not work as documented Initial Comment: According to the docs, I can use class names as type object, but that does not work. Strange enough, this is used in the python core modules (ie random.py): > python2.3 Python 2.3b2 (#2, Jun 30 2003, 10:50:53) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class a: ... def f (self): ... print 1 ... >>> class b(a): ... def f (self): ... super(b, self).f() ... print 2 ... >>> b().f() Traceback (most recent call last): File "", line 1, in ? File "", line 3, in f TypeError: super() argument 1 must be type, not classobj ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-07-01 20:45 Message: Logged In: YES user_id=89016 Fixed in: Doc/lib libfuncs.tex 1.140 ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-01 18:20 Message: Logged In: YES user_id=89016 super() only works for new style classes. This doesn't seem to be documented: neither in http://www.python.org/dev/doc/devel/lib/built-in-funcs.html nor in super.__doc__. Assigning to Fred. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764003&group_id=5470 From noreply@sourceforge.net Tue Jul 1 21:21:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 13:21:33 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-764188 ] setvbuf for File object Message-ID: Feature Requests item #764188, was opened at 2003-07-01 20:21 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=764188&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yue Luo (yueluo) Assigned to: Nobody/Anonymous (nobody) Summary: setvbuf for File object Initial Comment: I wonder if it is possible to add a new method setvbuf to File object. The method does the same as the setvbuf() in stdio.h. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 From noreply@sourceforge.net Tue Jul 1 21:27:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 13:27:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 00:33 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:27 Message: Logged In: YES user_id=357491 I knew it. Okay, I know exactly what the issue is and I came up with a way to deal with it. Problem is that I need to completely restructure how timezones are handled to do it. But it will simplify the code and help remove special casing. Unfortunately I am going to be taking a rather long drive today so I won't get to this today (I think; I have been known to say this and make it turn out to be a lie =). But I will get it down this week and have a patch to test. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 03:41 Message: Logged In: YES user_id=388573 Python 2.3b2+ (#1, Jul 1 2003, 10:37:33) [GCC 2.96 20000731 (ASPLinux 7.3 2.96-112)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.tzname ('UTC', 'UTC') >>> time.daylight 0 >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:03 Message: Logged In: YES user_id=357491 What is time.tzname and time.daylight set for both of you guys? ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 02:32 Message: Logged In: YES user_id=388573 New patch produce new error: ----------------------------- test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 299, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 1 test failed: test_strptime ------------------------------ Last time when I ran the test and it passed it was Python 2.3b1 (#1, Apr 28 2003, 11:09:08). ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 01:01 Message: Logged In: YES user_id=388573 Maybe it may helps: locale_time.timezone is ['UTC', 'GMT', 'UTC', ''] during testing ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 00:42 Message: Logged In: YES user_id=357491 Damn. OK, lets take Raymond's suggestion and try removing the time.tzset call. Try the new patch and let me know how it goes. Also, when was the last time you ran the test and it passed? I am trying to isolate if this is all happening because of my attempt to take time.daylight into account. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 00:25 Message: Logged In: YES user_id=388573 No, the same error remains ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 18:46 Message: Logged In: YES user_id=357491 So it wasn't what I thought it would be. But I do think I found the error. Dmitry, can you apply the patch that I attached to the report and see if it fixes the problem? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 16:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 05:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Tue Jul 1 21:29:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 13:29:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-763052 ] test_winsound, test_strptime fails in win2k Message-ID: Bugs item #763052, was opened at 2003-06-30 00:47 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Brett Cannon (bcannon) Summary: test_winsound, test_strptime fails in win2k Initial Comment: Hello, D:\apps\Python23>python -c "from test import test_winsound;test_winsound.test_ma in()" test_errors (test.test_winsound.BeepTest) ... ok test_extremes (test.test_winsound.BeepTest) ... ok test_increasingfrequency (test.test_winsound.BeepTest) ... ok test_asterisk (test.test_winsound.MessageBeepTest) ... ok test_default (test.test_winsound.MessageBeepTest) ... ok test_exclamation (test.test_winsound.MessageBeepTest) ... ok test_hand (test.test_winsound.MessageBeepTest) ... ok test_ok (test.test_winsound.MessageBeepTest) ... ok test_question (test.test_winsound.MessageBeepTest) ... ok test_alias_asterisk (test.test_winsound.PlaySoundTest) ... ok test_alias_exclamation (test.test_winsound.PlaySoundTest) ... ok test_alias_exit (test.test_winsound.PlaySoundTest) ... ok test_alias_fallback (test.test_winsound.PlaySoundTest) ... ok test_alias_hand (test.test_winsound.PlaySoundTest) ... ok test_alias_nofallback (test.test_winsound.PlaySoundTest) ... ok test_alias_question (test.test_winsound.PlaySoundTest) ... ok test_errors (test.test_winsound.PlaySoundTest) ... ok test_stopasync (test.test_winsound.PlaySoundTest) ... FAIL ====================================================================== FAIL: test_stopasync (test.test_winsound.PlaySoundTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------------------------------------------------- Ran 18 tests in 6.199s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_winsound.py", line 99, in test_main test_support.run_unittest(BeepTest, MessageBeepTest, PlaySoundTest) File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------- D:\apps\Python23>python -c "from test import test_strptime; test_strptime.test_m ain()" test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok test_by_hand_input (test.test_strptime.LocaleTime_Tests) ... ok test_date_time (test.test_strptime.LocaleTime_Tests) ... ok test_lang (test.test_strptime.LocaleTime_Tests) ... ok test_month (test.test_strptime.LocaleTime_Tests) ... ok test_timezone (test.test_strptime.LocaleTime_Tests) ... ok test_unknowntimezone (test.test_strptime.LocaleTime_Tests) ... ok test_weekday (test.test_strptime.LocaleTime_Tests) ... ok test_blankpattern (test.test_strptime.TimeRETests) ... ok test_compile (test.test_strptime.TimeRETests) ... ok test_getitem (test.test_strptime.TimeRETests) ... ok test_matching_with_escapes (test.test_strptime.TimeRETests) ... ok test_pattern (test.test_strptime.TimeRETests) ... ok test_pattern_escaping (test.test_strptime.TimeRETests) ... ok test_TypeError (test.test_strptime.StrptimeTests) ... ok test_caseinsensitive (test.test_strptime.StrptimeTests) ... ok test_date (test.test_strptime.StrptimeTests) ... ok test_date_time (test.test_strptime.StrptimeTests) ... ok test_day (test.test_strptime.StrptimeTests) ... ok test_defaults (test.test_strptime.StrptimeTests) ... ok test_hour (test.test_strptime.StrptimeTests) ... ok test_julian (test.test_strptime.StrptimeTests) ... ok test_minute (test.test_strptime.StrptimeTests) ... ok test_month (test.test_strptime.StrptimeTests) ... ok test_percent (test.test_strptime.StrptimeTests) ... ok test_second (test.test_strptime.StrptimeTests) ... ok test_time (test.test_strptime.StrptimeTests) ... ok test_timezone (test.test_strptime.StrptimeTests) ... FAIL test_unconverteddata (test.test_strptime.StrptimeTests) ... ok test_weekday (test.test_strptime.StrptimeTests) ... ok test_year (test.test_strptime.StrptimeTests) ... ok test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests) ... ok test_all_julian_days (test.test_strptime.JulianTests) ... ok test_day_of_week_calculation (test.test_strptime.CalculationTests) ... ok test_gregorian_calculation (test.test_strptime.CalculationTests) ... ok test_julian_calculation (test.test_strptime.CalculationTests) ... ok ====================================================================== FAIL: test_timezone (test.test_strptime.StrptimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- Ran 36 tests in 0.330s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_strptime.py", line 421, in test_main CalculationTests File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:29 Message: Logged In: YES user_id=357491 I figured out the error in my code. I am going to rework it (pretty much completely rewrite the timezone handling code) and it should hopefully solve the problem. As I said in the other bug, I am going on a long drive today so I doubt I will get to it today but I will do my best to get to it by the end of the week to have a patch to test. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-07-01 07:18 Message: Logged In: YES user_id=35752 I get the same error (if I remember correctly) on W2K if I set the timezone to Eastern and disable the daylight saving time correction check box. I think this sets the TZ to EST (instead of the usual EDT). ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 04:36 Message: Logged In: YES user_id=358087 Hello Brett, >>> import time >>> time.tzname ('Jerusalem Standard Time', 'Jerusalem Standard Time') >>> time.daylight 0 >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:09 Message: Logged In: YES user_id=357491 OK. I reponded in the other bug report asking both of you to tell me what time.tzname and time.daylight are set to. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 01:14 Message: Logged In: YES user_id=358087 Hello Brett, Sorry but no sigar (for both fixes). I'm attaching starck trace for both fixes. My time zone is GMT+2 (Jerusalem), and this is a laptop (IBM T30). Miki ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 18:49 Message: Logged In: YES user_id=357491 Miki, can you follow the test_strptime issues on bug #763047 ? It is the same problem and it will be easier to manage if you can follow along there. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 05:03 Message: Logged In: YES user_id=89016 The most likely reason for the winsound failure is, that your "SystemQuestion" sound has already finished before the second one starts, so there will be no RuntimeError exception. Checked in a fix as: Lib/test/test_winsound.py 1.6 Assigning to Brett Cannon for the strptime stuff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 From noreply@sourceforge.net Tue Jul 1 21:42:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 13:42:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-763708 ] Failures in test_macostools Message-ID: Bugs item #763708, was opened at 2003-06-30 23:54 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:42 Message: Logged In: YES user_id=357491 OK, Jack, here is your info: - 10.2.6 - Python 2.3b2+ straight from CVS (only way to code =) - HFS+ I believe (Finder says my HD is Mac OS Extended) Ran the test from my CVS tree with my installed version of Python 2.3b2+ (I can't do anything the standard way). I just ran it with the installed copy from the installed test directory and got the errors. I also just ran it with the compiled copy but not installed Python executable in my CVS tree and once again got the error. I noticed this came up, for me at least, when I was checking a patch for posixpath.py (which was applied to CVS). I checked the code, though, and didn't find a problem where anything changed to posixpath.py would affect it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 04:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply@sourceforge.net Tue Jul 1 22:13:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 14:13:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-763637 ] 2.3b2 unpack tuple of wrong size in after_cancel Message-ID: Bugs item #763637, was opened at 2003-06-30 22:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763637&group_id=5470 Category: Tkinter Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Cowles (mdcowles) >Assigned to: Neal Norwitz (nnorwitz) Summary: 2.3b2 unpack tuple of wrong size in after_cancel Initial Comment: The new code in after_cancel in the version of Tkinter.py that ships with 2.3b2: (script, type) = self.tk.splitlist( self.tk.call('after', 'info', id)) fails because the splitlist call returns something like ('after#53',) at least when linking against the Tcl and Tk 8.4 libraries that Fink installs under Mac OS X. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 17:13 Message: Logged In: YES user_id=33168 Ok, I updated the comment. Let me know if you have a better comment. Checked in as: * Lib/lib-tk/Tkinter.py 1.177 * Misc/NEWS 1.807 ---------------------------------------------------------------------- Comment By: Matthew Cowles (mdcowles) Date: 2003-07-01 13:31 Message: Logged In: YES user_id=198518 Yes, the patch works fine. With a little more investigation, I find that with Tcl 8.4 you sometimes get back a 2-tuple and sometimes a 1-tuple. So the comment is trivially misleading. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 23:58 Message: Logged In: YES user_id=33168 Matthew can you test the attached patch to verify if it fixes the problem. This (still) works for me on Tk 8.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763637&group_id=5470 From noreply@sourceforge.net Wed Jul 2 04:52:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 20:52:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-668980 ] classmethod does not check its arguments Message-ID: Bugs item #668980, was opened at 2003-01-16 05:22 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668980&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 1 Submitted By: Martin v. Löwis (loewis) >Assigned to: Martin v. Löwis (loewis) Summary: classmethod does not check its arguments Initial Comment: In 2.3a1, classmethod(3) works just fine. I think it should be a type error. It might be worthwhile to specialcase method objects, so that class X: def foo(self):pass X.foo=classmethod(X.foo) does the "right" thing, i.e. is equivalent to class X: def foo(self):pass foo=classmethod(foo) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 23:52 Message: Logged In: YES user_id=33168 classmethod(3) does raise a TypeError in 2.3b2. Should this be closed? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 09:52 Message: Logged In: YES user_id=6380 Not convinced; there are subtle things you might want to do with classmethod (and staticmethod) that a type check would prevent. I could live with something that checks whether the argument is callable. There are definitely some weird things: >>> C.x = classmethod(12) >>> C.x() Traceback (most recent call last): File "", line 1, in ? SystemError: ../Objects/classobject.c:2081: bad argument to internal function >>> vs. >>> C.x = staticmethod(12) >>> C.x() Traceback (most recent call last): File "", line 1, in ? TypeError: 'int' object is not callable >>> Anyway I have bigger fish to fry for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668980&group_id=5470 From noreply@sourceforge.net Wed Jul 2 05:02:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 21:02:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-764095 ] recent test_httplib change uses network Message-ID: Bugs item #764095, was opened at 2003-07-01 12:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764095&group_id=5470 Category: Python Library >Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) >Assigned to: Jeremy Hylton (jhylton) Summary: recent test_httplib change uses network Initial Comment: The 1.11 revision of test_httplib.py accesses www.python.org. The simplest fix is simply to add requires('network'), but the right fix imho is to mock the connection properly. I don't have a patch yet. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 23:02 Message: Logged In: YES user_id=80475 Jeremy authored rev 1.11. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764095&group_id=5470 From noreply@sourceforge.net Wed Jul 2 05:06:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 01 Jul 2003 21:06:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-764049 ] pythonw crashes under one windows platform (easy-everything) Message-ID: Bugs item #764049, was opened at 2003-07-01 11:47 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764049&group_id=5470 Category: Windows Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Angel Perea Martinez (angelpeream) Assigned to: Nobody/Anonymous (nobody) Summary: pythonw crashes under one windows platform (easy-everything) Initial Comment: pythonw (Python 2.3b2 (#43, Jun 29 2003, 16:43:04)) crashes (performs an invalid operation) under some special windows platform (easy-everything internet-cafe PCs). Previous versions showed no problem. Not surely a bug, but disencourages trying the language. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 23:06 Message: Logged In: YES user_id=80475 Do you have any idea of where it crashes? Can you dig in to it and find out which verison in CVS is the first to not run? Otherwise, it is like Tim says, the bug report is equilavent of saying the something appears wrong on the dark side of the moon. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-01 12:19 Message: Logged In: YES user_id=31435 Unassigned. If someone with access to such a platform doesn't dig into this, it appears hopeless. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764049&group_id=5470 From noreply@sourceforge.net Wed Jul 2 08:13:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 00:13:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-764437 ] AF_UNIX sockets do not handle Linux-specific addressing Message-ID: Bugs item #764437, was opened at 2003-07-02 02: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=764437&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Paul Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: AF_UNIX sockets do not handle Linux-specific addressing Initial Comment: As described in unix(7) manpage, Linux allows for special "kernel namespace" AF_UNIX sockets defined. With such sockets, the first byte of the path is \x00, and the rest is the address. These sockets do not show up in the filesystem. socketmodule.c:makesockaddr (as called by recvfrom) uses code like PyString_FromString(a->sun_path) to retrieve the address. This is incorrect -- on Linux, if the first byte of a->sun_path is null, the function should use PyString_FromStringAndSize to retrieve the full 108- byte buffer. I am not entirely sure that this is the only thing that needs to be fixed, but bind() and sendto() work with these sort of socket paths just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470 From noreply@sourceforge.net Wed Jul 2 08:56:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 00:56:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-764447 ] cvs update warnings Message-ID: Bugs item #764447, was opened at 2003-07-02 09:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764447&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Just van Rossum (jvr) Summary: cvs update warnings Initial Comment: On Windows, when you do "cvs update" in the "Mac/IDE scripts" directory, you get the following warnings (example uses Cygwin, but it also happens with other CVS clients): $ cd "Mac/IDE scripts"; cvs update ? Hold option to open a script ? Insert file name ? Insert folder name ? Search Python Documentation ? Hack/Remove .pyc files ? Hack/Toolbox Assistant cvs server: Updating . cvs server: Updating Hack cvs server: Updating Widget demos $ This is due to the fact that Windows can't deal with periods at the end of file names. All files giving warnings end in "...". These periods are removed when the files get created, and so CVS sees the files without periods and complains about them. At one level the solution is simple: rename those files. At another level, I don't know what the consequences are for the Mac, so assigning to Just (Jack doesn't seem to want to deal with this :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764447&group_id=5470 From noreply@sourceforge.net Wed Jul 2 10:33:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 02:33:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-764447 ] cvs update warnings Message-ID: Bugs item #764447, was opened at 2003-07-02 09:56 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764447&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Just van Rossum (jvr) Summary: cvs update warnings Initial Comment: On Windows, when you do "cvs update" in the "Mac/IDE scripts" directory, you get the following warnings (example uses Cygwin, but it also happens with other CVS clients): $ cd "Mac/IDE scripts"; cvs update ? Hold option to open a script ? Insert file name ? Insert folder name ? Search Python Documentation ? Hack/Remove .pyc files ? Hack/Toolbox Assistant cvs server: Updating . cvs server: Updating Hack cvs server: Updating Widget demos $ This is due to the fact that Windows can't deal with periods at the end of file names. All files giving warnings end in "...". These periods are removed when the files get created, and so CVS sees the files without periods and complains about them. At one level the solution is simple: rename those files. At another level, I don't know what the consequences are for the Mac, so assigning to Just (Jack doesn't seem to want to deal with this :-) ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-02 11:33 Message: Logged In: YES user_id=92689 Any objections to postponing this to after 2.3 final? The thing is, currently these file names map to menu items directly, and to fix this I have to build a way to specify the menu item from within the file. This will cause way more changes than I'm comfortable with, just before 2.3. Removing the spaces from folder names can be done at the same time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764447&group_id=5470 From noreply@sourceforge.net Wed Jul 2 11:09:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 03:09:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-764493 ] test test_nis crashed -- nis.error: no such key in map Message-ID: Bugs item #764493, was opened at 2003-07-02 12: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=764493&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Martin Mokrejs (mmokrejs) Assigned to: Nobody/Anonymous (nobody) Summary: test test_nis crashed -- nis.error: no such key in map Initial Comment: I always ignored this test error, but maybe you want to fix this: test test_nis crashed -- nis.error: no such key in map $ ./python Lib/test/test_nis.py nis.maps() group.bygid.tmp mail.aliases n.strack strack Traceback (most recent call last): File "Lib/test/test_nis.py", line 24, in ? if nis.match(k, nismap) != v: nis.error: no such key in map $ I believe this might be some misconfiguration of NIS on thsi host(we use it on other machines, but it should not be enabled on this particular machine). But, when I do "ypcat mail.aliases", I do not see a line with "n.strack strack". Maybe more debug trace would help to find what's going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764493&group_id=5470 From noreply@sourceforge.net Wed Jul 2 11:30:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 03:30:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-764504 ] doctest fails with TypeError Message-ID: Bugs item #764504, was opened at 2003-07-02 06: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=764504&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark J (average) Assigned to: Nobody/Anonymous (nobody) Summary: doctest fails with TypeError Initial Comment: #mymod.py: class base(dict): myupdate = dict.update #FINE def myfunc(self): pass class derive(base): myname = base.myfunc #FAILS import doctest, mymod doctest.testmod(mymod) ****** $ python2.3b2 mymod.py Traceback (most recent call last): File "mymod.py", line 8, in ? import doctest, mymod File "/home/me/mymod.py", line 9, in ? doctest.testmod(mymod) File "/usr/local/lib/python2.3/doctest.py", line 1137, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/local/lib/python2.3/doctest.py", line 900, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/local/lib/python2.3/doctest.py", line 1061, in __runone return self.rundoc(target, name) File "/usr/local/lib/python2.3/doctest.py", line 820, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/local/lib/python2.3/doctest.py", line 929, in run__test__ raise TypeError("Tester.run__test__: values in " TypeError: Tester.run__test__: values in dict must be strings, functions or classes; ****** Does not appear to be specific to Python v2.3. Thanks! Mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764504&group_id=5470 From noreply@sourceforge.net Wed Jul 2 11:36:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 03:36:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-764447 ] cvs update warnings Message-ID: Bugs item #764447, was opened at 2003-07-02 09:56 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764447&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sjoerd Mullender (sjoerd) Assigned to: Just van Rossum (jvr) Summary: cvs update warnings Initial Comment: On Windows, when you do "cvs update" in the "Mac/IDE scripts" directory, you get the following warnings (example uses Cygwin, but it also happens with other CVS clients): $ cd "Mac/IDE scripts"; cvs update ? Hold option to open a script ? Insert file name ? Insert folder name ? Search Python Documentation ? Hack/Remove .pyc files ? Hack/Toolbox Assistant cvs server: Updating . cvs server: Updating Hack cvs server: Updating Widget demos $ This is due to the fact that Windows can't deal with periods at the end of file names. All files giving warnings end in "...". These periods are removed when the files get created, and so CVS sees the files without periods and complains about them. At one level the solution is simple: rename those files. At another level, I don't know what the consequences are for the Mac, so assigning to Just (Jack doesn't seem to want to deal with this :-) ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2003-07-02 12:36 Message: Logged In: YES user_id=43607 I've lived with this for years. A few more weeks won't matter. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-02 11:33 Message: Logged In: YES user_id=92689 Any objections to postponing this to after 2.3 final? The thing is, currently these file names map to menu items directly, and to fix this I have to build a way to specify the menu item from within the file. This will cause way more changes than I'm comfortable with, just before 2.3. Removing the spaces from folder names can be done at the same time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764447&group_id=5470 From noreply@sourceforge.net Wed Jul 2 11:42:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 03:42:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-757822 ] Additional index items, other minor details Message-ID: Bugs item #757822, was opened at 2003-06-20 07:31 Message generated for change (Comment added) made by average You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757822&group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mark J (average) Assigned to: Nobody/Anonymous (nobody) Summary: Additional index items, other minor details Initial Comment: It seems that various recent language changes have not made it into any of the indices (super, property, __slots__, ...). LibRef: 3.14, first paragraph, last sentence unfinished "...to avoid confusing." 3.3, first paragraph after XXX: "Not all objects can be weakly referenced; those objects which do include class instances,..." If I get around to it myself, will try to submit patches for above :). Thanks... Mark ---------------------------------------------------------------------- >Comment By: Mark J (average) Date: 2003-07-02 06:42 Message: Logged In: YES user_id=127614 Sorry for the belated followup. The 3.3 note was to point out the mismatched verb ("can" changes to "do"): Re-write: "Not all objects can be weakly referenced; those objects which can include class instances, ..." Thanks, Mark ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-27 13:32 Message: Logged In: YES user_id=80475 Added docs and indexing for __metaclass__ and __slots__. The only thing left is your comment on 3.3 which looks fine to me. Closing bug and marking as fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-25 11:13 Message: Logged In: YES user_id=80475 super(), property(), classmethod(), object(), staticmethod() are now all in the index. They automatically make it there when their functions were documented. Sadly, __slots__ is not indexed because it is not yet documented. Fixed paragraph 3.14. See Doc/lib/libpickle.tex 1.42 For paragraph 3.3, it isn't clear what you want changed. Please let me know so we can clear this bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757822&group_id=5470 From noreply@sourceforge.net Wed Jul 2 13:08:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 05:08:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-668980 ] classmethod does not check its arguments Message-ID: Bugs item #668980, was opened at 2003-01-16 05:22 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668980&group_id=5470 Category: Type/class unification Group: None >Status: Closed Resolution: None Priority: 1 Submitted By: Martin v. Löwis (loewis) Assigned to: Martin v. Löwis (loewis) Summary: classmethod does not check its arguments Initial Comment: In 2.3a1, classmethod(3) works just fine. I think it should be a type error. It might be worthwhile to specialcase method objects, so that class X: def foo(self):pass X.foo=classmethod(X.foo) does the "right" thing, i.e. is equivalent to class X: def foo(self):pass foo=classmethod(foo) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-01 23:52 Message: Logged In: YES user_id=33168 classmethod(3) does raise a TypeError in 2.3b2. Should this be closed? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-01-16 09:52 Message: Logged In: YES user_id=6380 Not convinced; there are subtle things you might want to do with classmethod (and staticmethod) that a type check would prevent. I could live with something that checks whether the argument is callable. There are definitely some weird things: >>> C.x = classmethod(12) >>> C.x() Traceback (most recent call last): File "", line 1, in ? SystemError: ../Objects/classobject.c:2081: bad argument to internal function >>> vs. >>> C.x = staticmethod(12) >>> C.x() Traceback (most recent call last): File "", line 1, in ? TypeError: 'int' object is not callable >>> Anyway I have bigger fish to fry for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=668980&group_id=5470 From noreply@sourceforge.net Wed Jul 2 13:20:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 05:20:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-764548 ] SRE doesn't use isinstance Message-ID: Bugs item #764548, was opened at 2003-07-02 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=764548&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Fredrik Lundh (effbot) Summary: SRE doesn't use isinstance Initial Comment: The following code fails with a TypeError: #-------------------------------- import re class MyUnicode(unicode): pass val = MyUnicode("foobar") r = re.compile(val) #-------------------------------- This is caused by a check in sre.py: it checks if the type of the pattern is str or unicode, instead of testing if the value is an instance of those types. This is not a completely theoretical problem: PyObjC uses a subclass of unicode to represent Objective-C strings. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764548&group_id=5470 From noreply@sourceforge.net Wed Jul 2 13:38:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 05:38:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-764560 ] python treats IRIX64 and IRIX as different, but they are the Message-ID: Bugs item #764560, was opened at 2003-07-02 13: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=764560&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gordon Lack (gmlack) Assigned to: Nobody/Anonymous (nobody) Summary: python treats IRIX64 and IRIX as different, but they are the Initial Comment: Related to bug 216255 (116255?), but this goes deeper, as it refers to the *running* of python rather than just its building. If I build python on an Irix6.5 system (that is new/large) the tag "irix646" is used in the build/temp.* directory (and Lib/plat-*). This has several effects: a) the plat-irix6 directory from the standard distribution is ignored. b) running the tests on an IRIX system after compiling on an IRIX64 one causes it to rebuild everything, as it will look for temp.irix-6.5-2.2 and lib.irix-6.5-2.2 in build/ rather than the temp.irix64-6.5-2.2 and lib.irix64-6.5-2.2 which were actually built. c) running the same executable on a smaller system (a single installation, NFS mounted onto a large number of systems, for which "uname -s" returns IRIX, not IRIX64) will cause it to fail to find the </python2.2/Lib/plat-irix646 directory. (This might also affect 3rd party module installation?). IRIX and IRIX64 are the same when you build n32 binaries (which is what is built by default). Python should treat them the same. It should be possible to *configure* this OS tag at configure time (which would avoid this problem). Also, installing the "plat-irix646" directories under <> rather than <> would remove the need for such a tag in the installed files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764560&group_id=5470 From noreply@sourceforge.net Wed Jul 2 13:47:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 05:47:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-762198 ] bug in signal.signal -- raises SystemError Message-ID: Bugs item #762198, was opened at 2003-06-28 00:04 Message generated for change (Comment added) made by paryl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 1 Submitted By: Jim McCoy (mccoy) Assigned to: Nobody/Anonymous (nobody) Summary: bug in signal.signal -- raises SystemError Initial Comment: Summary pretty much says it all. Using Py2.2.3, win2k (sp4), and twisted 1.0.5 and the call that is triggering the error is as follows: signal.signal(signal.SIGINT, self.sigInt) returns "SystemError: error return without exception set" The twisted gang has tracked it down to a C error of some sort here... ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-02 12:47 Message: Logged In: YES user_id=813621 I already submitted a report on the wxWindows tracker... at the request of a couple of the Twisted guys, I replied to this thread too. I'm dying for a resolution on the matter, so if there's anywhere else I can post this info, please let me know. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-01 17:25 Message: Logged In: YES user_id=6380 OK, there's a clue. Do you know how to report bugs in wxPython? ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-01 17:22 Message: Logged In: YES user_id=813621 I can reproduce the problem without importing twisted... Win2k/Python 2.2.2/wxPython 2.4.1.2 >> from signal import * >> signal(SIGINT, lambda *a: None) does not give the error. >> from signal import * >> from wxPython.wx import * >> signal(SIGINT, lambda *a: None) gives the error. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 16:06 Message: Logged In: YES user_id=6380 I don't have Win2K, but on Win98 I can't reproduce it. The bug report is pretty incomplete -- the call doesn't seem to need Twisted, so what I tried was this: >>> from signal import * >>> signal(SIGINT, lambda *a: None) This returns the previous handler as it should. So please, send more precise data about the problem, or be ignored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 From noreply@sourceforge.net Wed Jul 2 14:12:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 06:12:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-762198 ] bug in signal.signal -- raises SystemError Message-ID: Bugs item #762198, was opened at 2003-06-27 20:04 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 Category: Python Library Group: Python 2.2.3 >Status: Closed Resolution: None Priority: 1 Submitted By: Jim McCoy (mccoy) Assigned to: Nobody/Anonymous (nobody) Summary: bug in signal.signal -- raises SystemError Initial Comment: Summary pretty much says it all. Using Py2.2.3, win2k (sp4), and twisted 1.0.5 and the call that is triggering the error is as follows: signal.signal(signal.SIGINT, self.sigInt) returns "SystemError: error return without exception set" The twisted gang has tracked it down to a C error of some sort here... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-02 09:12 Message: Logged In: YES user_id=6380 > I'm dying for a resolution on the matter If you really want this resolved, you're going to have to crawl into a debugger and work it yourself. Open Source means you get to contribute, too. :-) ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-02 08:47 Message: Logged In: YES user_id=813621 I already submitted a report on the wxWindows tracker... at the request of a couple of the Twisted guys, I replied to this thread too. I'm dying for a resolution on the matter, so if there's anywhere else I can post this info, please let me know. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-01 13:25 Message: Logged In: YES user_id=6380 OK, there's a clue. Do you know how to report bugs in wxPython? ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-01 13:22 Message: Logged In: YES user_id=813621 I can reproduce the problem without importing twisted... Win2k/Python 2.2.2/wxPython 2.4.1.2 >> from signal import * >> signal(SIGINT, lambda *a: None) does not give the error. >> from signal import * >> from wxPython.wx import * >> signal(SIGINT, lambda *a: None) gives the error. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 12:06 Message: Logged In: YES user_id=6380 I don't have Win2K, but on Win98 I can't reproduce it. The bug report is pretty incomplete -- the call doesn't seem to need Twisted, so what I tried was this: >>> from signal import * >>> signal(SIGINT, lambda *a: None) This returns the previous handler as it should. So please, send more precise data about the problem, or be ignored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 From noreply@sourceforge.net Wed Jul 2 15:22:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 07:22:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-764615 ] PackMan reissues error messages Message-ID: Bugs item #764615, was opened at 2003-07-02 16:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764615&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PackMan reissues error messages Initial Comment: If PackMan gives an error or warning when installing a package it will show that warning again when installing the next package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764615&group_id=5470 From noreply@sourceforge.net Wed Jul 2 15:23:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 07:23:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-764616 ] execfile(filename,...) not execfile(file,...) Message-ID: Bugs item #764616, was opened at 2003-07-02 09: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=764616&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Eger (davideger) Assigned to: Nobody/Anonymous (nobody) Summary: execfile(filename,...) not execfile(file,...) Initial Comment: At least with Python 2.2.2, execfile's first argument is a filename, whereas the documentation in lib/built-in-funcs.html indicates that the first argument is a file. Easy fix, patch the library reference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764616&group_id=5470 From noreply@sourceforge.net Wed Jul 2 15:54:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 07:54:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-764548 ] SRE doesn't use isinstance Message-ID: Bugs item #764548, was opened at 2003-07-02 14:20 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764548&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Fredrik Lundh (effbot) Summary: SRE doesn't use isinstance Initial Comment: The following code fails with a TypeError: #-------------------------------- import re class MyUnicode(unicode): pass val = MyUnicode("foobar") r = re.compile(val) #-------------------------------- This is caused by a check in sre.py: it checks if the type of the pattern is str or unicode, instead of testing if the value is an instance of those types. This is not a completely theoretical problem: PyObjC uses a subclass of unicode to represent Objective-C strings. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-02 16:54 Message: Logged In: YES user_id=92689 Here's a patch that should fix the problem, while remaining compatible with 1.5.2. Fredrik, please assign to me if you think the patch is ok. Preferably before 2.3 final is out ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764548&group_id=5470 From noreply@sourceforge.net Wed Jul 2 16:25:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 08:25:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-757822 ] Additional index items, other minor details Message-ID: Bugs item #757822, was opened at 2003-06-20 06:31 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757822&group_id=5470 Category: Documentation Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mark J (average) Assigned to: Nobody/Anonymous (nobody) Summary: Additional index items, other minor details Initial Comment: It seems that various recent language changes have not made it into any of the indices (super, property, __slots__, ...). LibRef: 3.14, first paragraph, last sentence unfinished "...to avoid confusing." 3.3, first paragraph after XXX: "Not all objects can be weakly referenced; those objects which do include class instances,..." If I get around to it myself, will try to submit patches for above :). Thanks... Mark ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-02 10:25 Message: Logged In: YES user_id=80475 Okay, that is fixed too. ---------------------------------------------------------------------- Comment By: Mark J (average) Date: 2003-07-02 05:42 Message: Logged In: YES user_id=127614 Sorry for the belated followup. The 3.3 note was to point out the mismatched verb ("can" changes to "do"): Re-write: "Not all objects can be weakly referenced; those objects which can include class instances, ..." Thanks, Mark ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-27 12:32 Message: Logged In: YES user_id=80475 Added docs and indexing for __metaclass__ and __slots__. The only thing left is your comment on 3.3 which looks fine to me. Closing bug and marking as fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-25 10:13 Message: Logged In: YES user_id=80475 super(), property(), classmethod(), object(), staticmethod() are now all in the index. They automatically make it there when their functions were documented. Sadly, __slots__ is not indexed because it is not yet documented. Fixed paragraph 3.14. See Doc/lib/libpickle.tex 1.42 For paragraph 3.3, it isn't clear what you want changed. Please let me know so we can clear this bug report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=757822&group_id=5470 From noreply@sourceforge.net Wed Jul 2 16:32:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 08:32:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-764616 ] execfile(filename,...) not execfile(file,...) Message-ID: Bugs item #764616, was opened at 2003-07-02 09:23 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764616&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Eger (davideger) Assigned to: Nobody/Anonymous (nobody) Summary: execfile(filename,...) not execfile(file,...) Initial Comment: At least with Python 2.2.2, execfile's first argument is a filename, whereas the documentation in lib/built-in-funcs.html indicates that the first argument is a file. Easy fix, patch the library reference. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-02 10:32 Message: Logged In: YES user_id=80475 Fixed. See libfuncs.tex 1.142. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764616&group_id=5470 From noreply@sourceforge.net Wed Jul 2 19:43:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 11:43:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-764548 ] SRE doesn't use isinstance Message-ID: Bugs item #764548, was opened at 2003-07-02 14:20 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764548&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Fredrik Lundh (effbot) Summary: SRE doesn't use isinstance Initial Comment: The following code fails with a TypeError: #-------------------------------- import re class MyUnicode(unicode): pass val = MyUnicode("foobar") r = re.compile(val) #-------------------------------- This is caused by a check in sre.py: it checks if the type of the pattern is str or unicode, instead of testing if the value is an instance of those types. This is not a completely theoretical problem: PyObjC uses a subclass of unicode to represent Objective-C strings. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2003-07-02 20:43 Message: Logged In: YES user_id=38376 Just, note that "isinstance" is supported in 1.5.2 (but unicode strings aren't). And I think it's safe to skip 1.5.2 support in SRE; I suggest changing the "baseline" to 2.1. If you agree, feel free to assign this item to your- self, and fix the code. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-02 16:54 Message: Logged In: YES user_id=92689 Here's a patch that should fix the problem, while remaining compatible with 1.5.2. Fredrik, please assign to me if you think the patch is ok. Preferably before 2.3 final is out ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764548&group_id=5470 From noreply@sourceforge.net Wed Jul 2 19:58:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 11:58:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-764548 ] SRE doesn't use isinstance Message-ID: Bugs item #764548, was opened at 2003-07-02 14:20 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764548&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Fredrik Lundh (effbot) Summary: SRE doesn't use isinstance Initial Comment: The following code fails with a TypeError: #-------------------------------- import re class MyUnicode(unicode): pass val = MyUnicode("foobar") r = re.compile(val) #-------------------------------- This is caused by a check in sre.py: it checks if the type of the pattern is str or unicode, instead of testing if the value is an instance of those types. This is not a completely theoretical problem: PyObjC uses a subclass of unicode to represent Objective-C strings. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-02 20:58 Message: Logged In: YES user_id=92689 D'oh, 1.5.2 is so long ago I could've sworn it didn't have isinstance(). However, 1.5.2 doesn't accept tuples for the second argument. I've attached a new patch, but it's so easy to still make it work with 1.5.2 that I didn't bother to break that compatibility ;- ) Shall I just go ahead and check it in? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-07-02 20:43 Message: Logged In: YES user_id=38376 Just, note that "isinstance" is supported in 1.5.2 (but unicode strings aren't). And I think it's safe to skip 1.5.2 support in SRE; I suggest changing the "baseline" to 2.1. If you agree, feel free to assign this item to your- self, and fix the code. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-02 16:54 Message: Logged In: YES user_id=92689 Here's a patch that should fix the problem, while remaining compatible with 1.5.2. Fredrik, please assign to me if you think the patch is ok. Preferably before 2.3 final is out ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764548&group_id=5470 From noreply@sourceforge.net Wed Jul 2 20:38:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 12:38:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-764437 ] AF_UNIX sockets do not handle Linux-specific addressing Message-ID: Bugs item #764437, was opened at 2003-07-02 02:13 Message generated for change (Settings changed) made by ppergame You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470 Category: Python Library >Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Paul Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: AF_UNIX sockets do not handle Linux-specific addressing Initial Comment: As described in unix(7) manpage, Linux allows for special "kernel namespace" AF_UNIX sockets defined. With such sockets, the first byte of the path is \x00, and the rest is the address. These sockets do not show up in the filesystem. socketmodule.c:makesockaddr (as called by recvfrom) uses code like PyString_FromString(a->sun_path) to retrieve the address. This is incorrect -- on Linux, if the first byte of a->sun_path is null, the function should use PyString_FromStringAndSize to retrieve the full 108- byte buffer. I am not entirely sure that this is the only thing that needs to be fixed, but bind() and sendto() work with these sort of socket paths just fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764437&group_id=5470 From noreply@sourceforge.net Wed Jul 2 20:39:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 12:39:46 -0700 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 12: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=764839&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Josh Hoyt (joshhoyt) Assigned to: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764839&group_id=5470 From noreply@sourceforge.net Wed Jul 2 20:47:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 12:47:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-764548 ] SRE doesn't use isinstance Message-ID: Bugs item #764548, was opened at 2003-07-02 14:20 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764548&group_id=5470 Category: Regular Expressions Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Just van Rossum (jvr) Summary: SRE doesn't use isinstance Initial Comment: The following code fails with a TypeError: #-------------------------------- import re class MyUnicode(unicode): pass val = MyUnicode("foobar") r = re.compile(val) #-------------------------------- This is caused by a check in sre.py: it checks if the type of the pattern is str or unicode, instead of testing if the value is an instance of those types. This is not a completely theoretical problem: PyObjC uses a subclass of unicode to represent Objective-C strings. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2003-07-02 21:47 Message: Logged In: YES user_id=38376 "Shall I just go ahead and check it in?" It would be most excellent if you did. Cheers /F ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-02 20:58 Message: Logged In: YES user_id=92689 D'oh, 1.5.2 is so long ago I could've sworn it didn't have isinstance(). However, 1.5.2 doesn't accept tuples for the second argument. I've attached a new patch, but it's so easy to still make it work with 1.5.2 that I didn't bother to break that compatibility ;- ) Shall I just go ahead and check it in? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-07-02 20:43 Message: Logged In: YES user_id=38376 Just, note that "isinstance" is supported in 1.5.2 (but unicode strings aren't). And I think it's safe to skip 1.5.2 support in SRE; I suggest changing the "baseline" to 2.1. If you agree, feel free to assign this item to your- self, and fix the code. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-02 16:54 Message: Logged In: YES user_id=92689 Here's a patch that should fix the problem, while remaining compatible with 1.5.2. Fredrik, please assign to me if you think the patch is ok. Preferably before 2.3 final is out ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764548&group_id=5470 From noreply@sourceforge.net Wed Jul 2 21:06:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 13:06:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-764548 ] SRE doesn't use isinstance Message-ID: Bugs item #764548, was opened at 2003-07-02 14:20 Message generated for change (Settings changed) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764548&group_id=5470 Category: Regular Expressions Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Just van Rossum (jvr) Summary: SRE doesn't use isinstance Initial Comment: The following code fails with a TypeError: #-------------------------------- import re class MyUnicode(unicode): pass val = MyUnicode("foobar") r = re.compile(val) #-------------------------------- This is caused by a check in sre.py: it checks if the type of the pattern is str or unicode, instead of testing if the value is an instance of those types. This is not a completely theoretical problem: PyObjC uses a subclass of unicode to represent Objective-C strings. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-02 22:06 Message: Logged In: YES user_id=92689 Most excellent dude! Committed to CVS as: Lib/sre.py, revision: 1.46 Lib/sre_compile.py, revision: 1.48 Lib/test/test_re.py, revision: 1.45 ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-07-02 21:47 Message: Logged In: YES user_id=38376 "Shall I just go ahead and check it in?" It would be most excellent if you did. Cheers /F ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-02 20:58 Message: Logged In: YES user_id=92689 D'oh, 1.5.2 is so long ago I could've sworn it didn't have isinstance(). However, 1.5.2 doesn't accept tuples for the second argument. I've attached a new patch, but it's so easy to still make it work with 1.5.2 that I didn't bother to break that compatibility ;- ) Shall I just go ahead and check it in? ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2003-07-02 20:43 Message: Logged In: YES user_id=38376 Just, note that "isinstance" is supported in 1.5.2 (but unicode strings aren't). And I think it's safe to skip 1.5.2 support in SRE; I suggest changing the "baseline" to 2.1. If you agree, feel free to assign this item to your- self, and fix the code. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-02 16:54 Message: Logged In: YES user_id=92689 Here's a patch that should fix the problem, while remaining compatible with 1.5.2. Fredrik, please assign to me if you think the patch is ok. Preferably before 2.3 final is out ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764548&group_id=5470 From noreply@sourceforge.net Wed Jul 2 22:34:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 14:34:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 00:33 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-02 14:34 Message: Logged In: YES user_id=357491 OK, so I didn't need to completely restructure how timezones are handled (although I will for Python 2.4). The new patch adds a check to see if time.daylight is true or not to decide whether it should worry about duplicate values in time.tzname . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:27 Message: Logged In: YES user_id=357491 I knew it. Okay, I know exactly what the issue is and I came up with a way to deal with it. Problem is that I need to completely restructure how timezones are handled to do it. But it will simplify the code and help remove special casing. Unfortunately I am going to be taking a rather long drive today so I won't get to this today (I think; I have been known to say this and make it turn out to be a lie =). But I will get it down this week and have a patch to test. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 03:41 Message: Logged In: YES user_id=388573 Python 2.3b2+ (#1, Jul 1 2003, 10:37:33) [GCC 2.96 20000731 (ASPLinux 7.3 2.96-112)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.tzname ('UTC', 'UTC') >>> time.daylight 0 >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:03 Message: Logged In: YES user_id=357491 What is time.tzname and time.daylight set for both of you guys? ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 02:32 Message: Logged In: YES user_id=388573 New patch produce new error: ----------------------------- test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 299, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 1 test failed: test_strptime ------------------------------ Last time when I ran the test and it passed it was Python 2.3b1 (#1, Apr 28 2003, 11:09:08). ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 01:01 Message: Logged In: YES user_id=388573 Maybe it may helps: locale_time.timezone is ['UTC', 'GMT', 'UTC', ''] during testing ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 00:42 Message: Logged In: YES user_id=357491 Damn. OK, lets take Raymond's suggestion and try removing the time.tzset call. Try the new patch and let me know how it goes. Also, when was the last time you ran the test and it passed? I am trying to isolate if this is all happening because of my attempt to take time.daylight into account. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 00:25 Message: Logged In: YES user_id=388573 No, the same error remains ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 18:46 Message: Logged In: YES user_id=357491 So it wasn't what I thought it would be. But I do think I found the error. Dmitry, can you apply the patch that I attached to the report and see if it fixes the problem? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 16:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 05:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Wed Jul 2 22:35:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 14:35:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-763052 ] test_winsound, test_strptime fails in win2k Message-ID: Bugs item #763052, was opened at 2003-06-30 00:47 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Brett Cannon (bcannon) Summary: test_winsound, test_strptime fails in win2k Initial Comment: Hello, D:\apps\Python23>python -c "from test import test_winsound;test_winsound.test_ma in()" test_errors (test.test_winsound.BeepTest) ... ok test_extremes (test.test_winsound.BeepTest) ... ok test_increasingfrequency (test.test_winsound.BeepTest) ... ok test_asterisk (test.test_winsound.MessageBeepTest) ... ok test_default (test.test_winsound.MessageBeepTest) ... ok test_exclamation (test.test_winsound.MessageBeepTest) ... ok test_hand (test.test_winsound.MessageBeepTest) ... ok test_ok (test.test_winsound.MessageBeepTest) ... ok test_question (test.test_winsound.MessageBeepTest) ... ok test_alias_asterisk (test.test_winsound.PlaySoundTest) ... ok test_alias_exclamation (test.test_winsound.PlaySoundTest) ... ok test_alias_exit (test.test_winsound.PlaySoundTest) ... ok test_alias_fallback (test.test_winsound.PlaySoundTest) ... ok test_alias_hand (test.test_winsound.PlaySoundTest) ... ok test_alias_nofallback (test.test_winsound.PlaySoundTest) ... ok test_alias_question (test.test_winsound.PlaySoundTest) ... ok test_errors (test.test_winsound.PlaySoundTest) ... ok test_stopasync (test.test_winsound.PlaySoundTest) ... FAIL ====================================================================== FAIL: test_stopasync (test.test_winsound.PlaySoundTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------------------------------------------------- Ran 18 tests in 6.199s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_winsound.py", line 99, in test_main test_support.run_unittest(BeepTest, MessageBeepTest, PlaySoundTest) File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------- D:\apps\Python23>python -c "from test import test_strptime; test_strptime.test_m ain()" test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok test_by_hand_input (test.test_strptime.LocaleTime_Tests) ... ok test_date_time (test.test_strptime.LocaleTime_Tests) ... ok test_lang (test.test_strptime.LocaleTime_Tests) ... ok test_month (test.test_strptime.LocaleTime_Tests) ... ok test_timezone (test.test_strptime.LocaleTime_Tests) ... ok test_unknowntimezone (test.test_strptime.LocaleTime_Tests) ... ok test_weekday (test.test_strptime.LocaleTime_Tests) ... ok test_blankpattern (test.test_strptime.TimeRETests) ... ok test_compile (test.test_strptime.TimeRETests) ... ok test_getitem (test.test_strptime.TimeRETests) ... ok test_matching_with_escapes (test.test_strptime.TimeRETests) ... ok test_pattern (test.test_strptime.TimeRETests) ... ok test_pattern_escaping (test.test_strptime.TimeRETests) ... ok test_TypeError (test.test_strptime.StrptimeTests) ... ok test_caseinsensitive (test.test_strptime.StrptimeTests) ... ok test_date (test.test_strptime.StrptimeTests) ... ok test_date_time (test.test_strptime.StrptimeTests) ... ok test_day (test.test_strptime.StrptimeTests) ... ok test_defaults (test.test_strptime.StrptimeTests) ... ok test_hour (test.test_strptime.StrptimeTests) ... ok test_julian (test.test_strptime.StrptimeTests) ... ok test_minute (test.test_strptime.StrptimeTests) ... ok test_month (test.test_strptime.StrptimeTests) ... ok test_percent (test.test_strptime.StrptimeTests) ... ok test_second (test.test_strptime.StrptimeTests) ... ok test_time (test.test_strptime.StrptimeTests) ... ok test_timezone (test.test_strptime.StrptimeTests) ... FAIL test_unconverteddata (test.test_strptime.StrptimeTests) ... ok test_weekday (test.test_strptime.StrptimeTests) ... ok test_year (test.test_strptime.StrptimeTests) ... ok test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests) ... ok test_all_julian_days (test.test_strptime.JulianTests) ... ok test_day_of_week_calculation (test.test_strptime.CalculationTests) ... ok test_gregorian_calculation (test.test_strptime.CalculationTests) ... ok test_julian_calculation (test.test_strptime.CalculationTests) ... ok ====================================================================== FAIL: test_timezone (test.test_strptime.StrptimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- Ran 36 tests in 0.330s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_strptime.py", line 421, in test_main CalculationTests File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-02 14:35 Message: Logged In: YES user_id=357491 The other bug report has a new patch to try out. Obviously let me know if it works. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:29 Message: Logged In: YES user_id=357491 I figured out the error in my code. I am going to rework it (pretty much completely rewrite the timezone handling code) and it should hopefully solve the problem. As I said in the other bug, I am going on a long drive today so I doubt I will get to it today but I will do my best to get to it by the end of the week to have a patch to test. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-07-01 07:18 Message: Logged In: YES user_id=35752 I get the same error (if I remember correctly) on W2K if I set the timezone to Eastern and disable the daylight saving time correction check box. I think this sets the TZ to EST (instead of the usual EDT). ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 04:36 Message: Logged In: YES user_id=358087 Hello Brett, >>> import time >>> time.tzname ('Jerusalem Standard Time', 'Jerusalem Standard Time') >>> time.daylight 0 >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:09 Message: Logged In: YES user_id=357491 OK. I reponded in the other bug report asking both of you to tell me what time.tzname and time.daylight are set to. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 01:14 Message: Logged In: YES user_id=358087 Hello Brett, Sorry but no sigar (for both fixes). I'm attaching starck trace for both fixes. My time zone is GMT+2 (Jerusalem), and this is a laptop (IBM T30). Miki ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 18:49 Message: Logged In: YES user_id=357491 Miki, can you follow the test_strptime issues on bug #763047 ? It is the same problem and it will be easier to manage if you can follow along there. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 05:03 Message: Logged In: YES user_id=89016 The most likely reason for the winsound failure is, that your "SystemQuestion" sound has already finished before the second one starts, so there will be no RuntimeError exception. Checked in a fix as: Lib/test/test_winsound.py 1.6 Assigning to Brett Cannon for the strptime stuff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 From noreply@sourceforge.net Wed Jul 2 23:31:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 15:31:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-764095 ] recent test_httplib change uses network Message-ID: Bugs item #764095, was opened at 2003-07-01 11:22 Message generated for change (Comment added) made by staschuk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764095&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Jeremy Hylton (jhylton) Summary: recent test_httplib change uses network Initial Comment: The 1.11 revision of test_httplib.py accesses www.python.org. The simplest fix is simply to add requires('network'), but the right fix imho is to mock the connection properly. I don't have a patch yet. ---------------------------------------------------------------------- >Comment By: Steven Taschuk (staschuk) Date: 2003-07-02 16:31 Message: Logged In: YES user_id=666873 Attached a patch to make the test tickle bug 622042 as desired but not access www.python.org or otherwise require the network resource. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 22:02 Message: Logged In: YES user_id=80475 Jeremy authored rev 1.11. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764095&group_id=5470 From noreply@sourceforge.net Wed Jul 2 23:45:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 15:45:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-764975 ] Installing 2.3b2 on to non-system disk fails Message-ID: Bugs item #764975, was opened at 2003-07-02 22:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764975&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Rob Managan (managan) Assigned to: Jack Jansen (jackjansen) Summary: Installing 2.3b2 on to non-system disk fails Initial Comment: When installing 2.3b2 I was allowed to choose a non-system disk. It did create an Applications folder and installed into it. Parts of the framework were installed correctly (based onmod dates) but it did not work properly. After installing on the system disk the IDE worked fine but the package manager did not except from within the IDE. I suspect double clicking on the Package Manager was trying to use an older version of python, possibly Apple's. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764975&group_id=5470 From noreply@sourceforge.net Thu Jul 3 00:10:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 16:10:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 07:33 Message generated for change (Comment added) made by prjsf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-07-02 23:10 Message: Logged In: YES user_id=412110 I had the same problem; tz_daylight.diff indeed fixes it for me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-02 21:34 Message: Logged In: YES user_id=357491 OK, so I didn't need to completely restructure how timezones are handled (although I will for Python 2.4). The new patch adds a check to see if time.daylight is true or not to decide whether it should worry about duplicate values in time.tzname . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 20:27 Message: Logged In: YES user_id=357491 I knew it. Okay, I know exactly what the issue is and I came up with a way to deal with it. Problem is that I need to completely restructure how timezones are handled to do it. But it will simplify the code and help remove special casing. Unfortunately I am going to be taking a rather long drive today so I won't get to this today (I think; I have been known to say this and make it turn out to be a lie =). But I will get it down this week and have a patch to test. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 10:41 Message: Logged In: YES user_id=388573 Python 2.3b2+ (#1, Jul 1 2003, 10:37:33) [GCC 2.96 20000731 (ASPLinux 7.3 2.96-112)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.tzname ('UTC', 'UTC') >>> time.daylight 0 >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 10:03 Message: Logged In: YES user_id=357491 What is time.tzname and time.daylight set for both of you guys? ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 09:32 Message: Logged In: YES user_id=388573 New patch produce new error: ----------------------------- test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 299, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 1 test failed: test_strptime ------------------------------ Last time when I ran the test and it passed it was Python 2.3b1 (#1, Apr 28 2003, 11:09:08). ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 08:01 Message: Logged In: YES user_id=388573 Maybe it may helps: locale_time.timezone is ['UTC', 'GMT', 'UTC', ''] during testing ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 07:42 Message: Logged In: YES user_id=357491 Damn. OK, lets take Raymond's suggestion and try removing the time.tzset call. Try the new patch and let me know how it goes. Also, when was the last time you ran the test and it passed? I am trying to isolate if this is all happening because of my attempt to take time.daylight into account. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 07:25 Message: Logged In: YES user_id=388573 No, the same error remains ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 01:46 Message: Logged In: YES user_id=357491 So it wasn't what I thought it would be. But I do think I found the error. Dmitry, can you apply the patch that I attached to the report and see if it fixes the problem? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 23:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 12:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Thu Jul 3 02:52:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 02 Jul 2003 18:52:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-765036 ] Unicode non-characters Message-ID: Bugs item #765036, was opened at 2003-07-03 01:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765036&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gnosis Software (gnosis) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode non-characters Initial Comment: The alleged codepoints unichr(0xFFFE) and unichr(0xFFFF) are not unicode characters. This document: http://www.unicode.org/charts/PDF/UFFF0.pdf Contains: Noncharacters These codes are intended for process internal uses, but are not permitted for interchange. FFFE ! ¨ the value FFFE !is guaranteed not to be a Unicode character at all ¨ may be used to detect byte order by contrast with FEFF which is a character FEFF zero width no-break space FFFF ! ¨ the value FFFF !is guaranteed not to be a Unicode character at all In particular, an XML document that contains such an alleged unicode entity in not well-formed. All unicode-aware versions of Python threat these codepoints in the same manner as other codepoints, e.g. both unichr(0xFFFE) and u'\uffff' pass without complaint. I believe the correct behavior would be for Python to raise an exception, or at least a warning, on access to these spurious characters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765036&group_id=5470 From noreply@sourceforge.net Thu Jul 3 08:07:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 00:07:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-765036 ] Unicode non-characters Message-ID: Bugs item #765036, was opened at 2003-07-03 03:52 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765036&group_id=5470 Category: Unicode Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Gnosis Software (gnosis) Assigned to: M.-A. Lemburg (lemburg) Summary: Unicode non-characters Initial Comment: The alleged codepoints unichr(0xFFFE) and unichr(0xFFFF) are not unicode characters. This document: http://www.unicode.org/charts/PDF/UFFF0.pdf Contains: Noncharacters These codes are intended for process internal uses, but are not permitted for interchange. FFFE ! ¨ the value FFFE !is guaranteed not to be a Unicode character at all ¨ may be used to detect byte order by contrast with FEFF which is a character FEFF zero width no-break space FFFF ! ¨ the value FFFF !is guaranteed not to be a Unicode character at all In particular, an XML document that contains such an alleged unicode entity in not well-formed. All unicode-aware versions of Python threat these codepoints in the same manner as other codepoints, e.g. both unichr(0xFFFE) and u'\uffff' pass without complaint. I believe the correct behavior would be for Python to raise an exception, or at least a warning, on access to these spurious characters. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-07-03 09:07 Message: Logged In: YES user_id=38388 This is on purpose: you do need a way to write programs which write and handle BOMs. If you want your program to raise exceptions for these character points, you can easily implement the required checks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765036&group_id=5470 From noreply@sourceforge.net Thu Jul 3 08:24:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 00:24:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-763052 ] test_winsound, test_strptime fails in win2k Message-ID: Bugs item #763052, was opened at 2003-06-30 10:47 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Brett Cannon (bcannon) Summary: test_winsound, test_strptime fails in win2k Initial Comment: Hello, D:\apps\Python23>python -c "from test import test_winsound;test_winsound.test_ma in()" test_errors (test.test_winsound.BeepTest) ... ok test_extremes (test.test_winsound.BeepTest) ... ok test_increasingfrequency (test.test_winsound.BeepTest) ... ok test_asterisk (test.test_winsound.MessageBeepTest) ... ok test_default (test.test_winsound.MessageBeepTest) ... ok test_exclamation (test.test_winsound.MessageBeepTest) ... ok test_hand (test.test_winsound.MessageBeepTest) ... ok test_ok (test.test_winsound.MessageBeepTest) ... ok test_question (test.test_winsound.MessageBeepTest) ... ok test_alias_asterisk (test.test_winsound.PlaySoundTest) ... ok test_alias_exclamation (test.test_winsound.PlaySoundTest) ... ok test_alias_exit (test.test_winsound.PlaySoundTest) ... ok test_alias_fallback (test.test_winsound.PlaySoundTest) ... ok test_alias_hand (test.test_winsound.PlaySoundTest) ... ok test_alias_nofallback (test.test_winsound.PlaySoundTest) ... ok test_alias_question (test.test_winsound.PlaySoundTest) ... ok test_errors (test.test_winsound.PlaySoundTest) ... ok test_stopasync (test.test_winsound.PlaySoundTest) ... FAIL ====================================================================== FAIL: test_stopasync (test.test_winsound.PlaySoundTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------------------------------------------------- Ran 18 tests in 6.199s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_winsound.py", line 99, in test_main test_support.run_unittest(BeepTest, MessageBeepTest, PlaySoundTest) File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------- D:\apps\Python23>python -c "from test import test_strptime; test_strptime.test_m ain()" test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok test_by_hand_input (test.test_strptime.LocaleTime_Tests) ... ok test_date_time (test.test_strptime.LocaleTime_Tests) ... ok test_lang (test.test_strptime.LocaleTime_Tests) ... ok test_month (test.test_strptime.LocaleTime_Tests) ... ok test_timezone (test.test_strptime.LocaleTime_Tests) ... ok test_unknowntimezone (test.test_strptime.LocaleTime_Tests) ... ok test_weekday (test.test_strptime.LocaleTime_Tests) ... ok test_blankpattern (test.test_strptime.TimeRETests) ... ok test_compile (test.test_strptime.TimeRETests) ... ok test_getitem (test.test_strptime.TimeRETests) ... ok test_matching_with_escapes (test.test_strptime.TimeRETests) ... ok test_pattern (test.test_strptime.TimeRETests) ... ok test_pattern_escaping (test.test_strptime.TimeRETests) ... ok test_TypeError (test.test_strptime.StrptimeTests) ... ok test_caseinsensitive (test.test_strptime.StrptimeTests) ... ok test_date (test.test_strptime.StrptimeTests) ... ok test_date_time (test.test_strptime.StrptimeTests) ... ok test_day (test.test_strptime.StrptimeTests) ... ok test_defaults (test.test_strptime.StrptimeTests) ... ok test_hour (test.test_strptime.StrptimeTests) ... ok test_julian (test.test_strptime.StrptimeTests) ... ok test_minute (test.test_strptime.StrptimeTests) ... ok test_month (test.test_strptime.StrptimeTests) ... ok test_percent (test.test_strptime.StrptimeTests) ... ok test_second (test.test_strptime.StrptimeTests) ... ok test_time (test.test_strptime.StrptimeTests) ... ok test_timezone (test.test_strptime.StrptimeTests) ... FAIL test_unconverteddata (test.test_strptime.StrptimeTests) ... ok test_weekday (test.test_strptime.StrptimeTests) ... ok test_year (test.test_strptime.StrptimeTests) ... ok test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests) ... ok test_all_julian_days (test.test_strptime.JulianTests) ... ok test_day_of_week_calculation (test.test_strptime.CalculationTests) ... ok test_gregorian_calculation (test.test_strptime.CalculationTests) ... ok test_julian_calculation (test.test_strptime.CalculationTests) ... ok ====================================================================== FAIL: test_timezone (test.test_strptime.StrptimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- Ran 36 tests in 0.330s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_strptime.py", line 421, in test_main CalculationTests File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2003-07-03 10:24 Message: Logged In: YES user_id=358087 Hello Brett, OK. Now it works. 10x. Miki ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-03 00:35 Message: Logged In: YES user_id=357491 The other bug report has a new patch to try out. Obviously let me know if it works. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 23:29 Message: Logged In: YES user_id=357491 I figured out the error in my code. I am going to rework it (pretty much completely rewrite the timezone handling code) and it should hopefully solve the problem. As I said in the other bug, I am going on a long drive today so I doubt I will get to it today but I will do my best to get to it by the end of the week to have a patch to test. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-07-01 17:18 Message: Logged In: YES user_id=35752 I get the same error (if I remember correctly) on W2K if I set the timezone to Eastern and disable the daylight saving time correction check box. I think this sets the TZ to EST (instead of the usual EDT). ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 14:36 Message: Logged In: YES user_id=358087 Hello Brett, >>> import time >>> time.tzname ('Jerusalem Standard Time', 'Jerusalem Standard Time') >>> time.daylight 0 >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:09 Message: Logged In: YES user_id=357491 OK. I reponded in the other bug report asking both of you to tell me what time.tzname and time.daylight are set to. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 11:14 Message: Logged In: YES user_id=358087 Hello Brett, Sorry but no sigar (for both fixes). I'm attaching starck trace for both fixes. My time zone is GMT+2 (Jerusalem), and this is a laptop (IBM T30). Miki ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 04:49 Message: Logged In: YES user_id=357491 Miki, can you follow the test_strptime issues on bug #763047 ? It is the same problem and it will be easier to manage if you can follow along there. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 15:03 Message: Logged In: YES user_id=89016 The most likely reason for the winsound failure is, that your "SystemQuestion" sound has already finished before the second one starts, so there will be no RuntimeError exception. Checked in a fix as: Lib/test/test_winsound.py 1.6 Assigning to Brett Cannon for the strptime stuff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 From noreply@sourceforge.net Thu Jul 3 10:12:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 02:12:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 11:33 Message generated for change (Comment added) made by hdima You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- >Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-03 13:12 Message: Logged In: YES user_id=388573 Ok, tz_daylight.diff fixes the problem. ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-07-03 03:10 Message: Logged In: YES user_id=412110 I had the same problem; tz_daylight.diff indeed fixes it for me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-03 01:34 Message: Logged In: YES user_id=357491 OK, so I didn't need to completely restructure how timezones are handled (although I will for Python 2.4). The new patch adds a check to see if time.daylight is true or not to decide whether it should worry about duplicate values in time.tzname . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-02 00:27 Message: Logged In: YES user_id=357491 I knew it. Okay, I know exactly what the issue is and I came up with a way to deal with it. Problem is that I need to completely restructure how timezones are handled to do it. But it will simplify the code and help remove special casing. Unfortunately I am going to be taking a rather long drive today so I won't get to this today (I think; I have been known to say this and make it turn out to be a lie =). But I will get it down this week and have a patch to test. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 14:41 Message: Logged In: YES user_id=388573 Python 2.3b2+ (#1, Jul 1 2003, 10:37:33) [GCC 2.96 20000731 (ASPLinux 7.3 2.96-112)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.tzname ('UTC', 'UTC') >>> time.daylight 0 >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 14:03 Message: Logged In: YES user_id=357491 What is time.tzname and time.daylight set for both of you guys? ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 13:32 Message: Logged In: YES user_id=388573 New patch produce new error: ----------------------------- test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 299, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 1 test failed: test_strptime ------------------------------ Last time when I ran the test and it passed it was Python 2.3b1 (#1, Apr 28 2003, 11:09:08). ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 12:01 Message: Logged In: YES user_id=388573 Maybe it may helps: locale_time.timezone is ['UTC', 'GMT', 'UTC', ''] during testing ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 11:42 Message: Logged In: YES user_id=357491 Damn. OK, lets take Raymond's suggestion and try removing the time.tzset call. Try the new patch and let me know how it goes. Also, when was the last time you ran the test and it passed? I am trying to isolate if this is all happening because of my attempt to take time.daylight into account. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 11:25 Message: Logged In: YES user_id=388573 No, the same error remains ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 05:46 Message: Logged In: YES user_id=357491 So it wasn't what I thought it would be. But I do think I found the error. Dmitry, can you apply the patch that I attached to the report and see if it fixes the problem? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 16:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Thu Jul 3 11:32:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 03:32:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-765228 ] Subclassing from Modules Message-ID: Bugs item #765228, was opened at 2003-07-03 12: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=765228&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Nobody/Anonymous (nobody) Summary: Subclassing from Modules Initial Comment: In Python 2.2.3 there's a problem with accidental subclassing from a Python module, e.g. import MyStuff class A(MyStuff): pass this gives no error until you try to instantiate the class: o = A() TypeError: 'module' object is not callable In Python 2.3 the error is generated at module startup time: class A(MyStuff): pass TypeError: function takes at most 2 arguments (3 given) Since it is rather common that you create modules which have the same name as their most important class, I would find it more appropriate to raise a TypeError with a message "can't subclass a module instance" in both versions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765228&group_id=5470 From noreply@sourceforge.net Thu Jul 3 13:47:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 05:47:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-762198 ] bug in signal.signal -- raises SystemError Message-ID: Bugs item #762198, was opened at 2003-06-28 00:04 Message generated for change (Comment added) made by paryl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Closed Resolution: None Priority: 1 Submitted By: Jim McCoy (mccoy) Assigned to: Nobody/Anonymous (nobody) Summary: bug in signal.signal -- raises SystemError Initial Comment: Summary pretty much says it all. Using Py2.2.3, win2k (sp4), and twisted 1.0.5 and the call that is triggering the error is as follows: signal.signal(signal.SIGINT, self.sigInt) returns "SystemError: error return without exception set" The twisted gang has tracked it down to a C error of some sort here... ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-03 12:47 Message: Logged In: YES user_id=813621 my, my. I do contribute, in fact. Unfortunately, not knowing the many facets of wxWindows is a small (read: large) problem. Generally you get the people that actually work on a package to fix the package... I find it best to follow the 'non-nuked planet scenario' where getting something done doesn't mean learning it all from scratch because no one else exists with the knowledge. Call me crazy... I mean no offense, of course. ;) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-02 13:12 Message: Logged In: YES user_id=6380 > I'm dying for a resolution on the matter If you really want this resolved, you're going to have to crawl into a debugger and work it yourself. Open Source means you get to contribute, too. :-) ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-02 12:47 Message: Logged In: YES user_id=813621 I already submitted a report on the wxWindows tracker... at the request of a couple of the Twisted guys, I replied to this thread too. I'm dying for a resolution on the matter, so if there's anywhere else I can post this info, please let me know. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-01 17:25 Message: Logged In: YES user_id=6380 OK, there's a clue. Do you know how to report bugs in wxPython? ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-01 17:22 Message: Logged In: YES user_id=813621 I can reproduce the problem without importing twisted... Win2k/Python 2.2.2/wxPython 2.4.1.2 >> from signal import * >> signal(SIGINT, lambda *a: None) does not give the error. >> from signal import * >> from wxPython.wx import * >> signal(SIGINT, lambda *a: None) gives the error. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 16:06 Message: Logged In: YES user_id=6380 I don't have Win2K, but on Win98 I can't reproduce it. The bug report is pretty incomplete -- the call doesn't seem to need Twisted, so what I tried was this: >>> from signal import * >>> signal(SIGINT, lambda *a: None) This returns the previous handler as it should. So please, send more precise data about the problem, or be ignored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 From noreply@sourceforge.net Thu Jul 3 14:06:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 06:06:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-762198 ] bug in signal.signal -- raises SystemError Message-ID: Bugs item #762198, was opened at 2003-06-27 20:04 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Closed Resolution: None Priority: 1 Submitted By: Jim McCoy (mccoy) Assigned to: Nobody/Anonymous (nobody) Summary: bug in signal.signal -- raises SystemError Initial Comment: Summary pretty much says it all. Using Py2.2.3, win2k (sp4), and twisted 1.0.5 and the call that is triggering the error is as follows: signal.signal(signal.SIGINT, self.sigInt) returns "SystemError: error return without exception set" The twisted gang has tracked it down to a C error of some sort here... ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-03 09:06 Message: Logged In: YES user_id=6380 > Generally you get the people that actually work on a package > to fix the package... Right. And since they do it in their spare time, you don't get to tell them what their priorities should be. ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-03 08:47 Message: Logged In: YES user_id=813621 my, my. I do contribute, in fact. Unfortunately, not knowing the many facets of wxWindows is a small (read: large) problem. Generally you get the people that actually work on a package to fix the package... I find it best to follow the 'non-nuked planet scenario' where getting something done doesn't mean learning it all from scratch because no one else exists with the knowledge. Call me crazy... I mean no offense, of course. ;) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-02 09:12 Message: Logged In: YES user_id=6380 > I'm dying for a resolution on the matter If you really want this resolved, you're going to have to crawl into a debugger and work it yourself. Open Source means you get to contribute, too. :-) ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-02 08:47 Message: Logged In: YES user_id=813621 I already submitted a report on the wxWindows tracker... at the request of a couple of the Twisted guys, I replied to this thread too. I'm dying for a resolution on the matter, so if there's anywhere else I can post this info, please let me know. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-01 13:25 Message: Logged In: YES user_id=6380 OK, there's a clue. Do you know how to report bugs in wxPython? ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-01 13:22 Message: Logged In: YES user_id=813621 I can reproduce the problem without importing twisted... Win2k/Python 2.2.2/wxPython 2.4.1.2 >> from signal import * >> signal(SIGINT, lambda *a: None) does not give the error. >> from signal import * >> from wxPython.wx import * >> signal(SIGINT, lambda *a: None) gives the error. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 12:06 Message: Logged In: YES user_id=6380 I don't have Win2K, but on Win98 I can't reproduce it. The bug report is pretty incomplete -- the call doesn't seem to need Twisted, so what I tried was this: >>> from signal import * >>> signal(SIGINT, lambda *a: None) This returns the previous handler as it should. So please, send more precise data about the problem, or be ignored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 From noreply@sourceforge.net Thu Jul 3 17:42:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 09:42:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-765456 ] test zipimport fails Message-ID: Bugs item #765456, was opened at 2003-07-03 11: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=765456&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Friedrich (robinf1) Assigned to: Nobody/Anonymous (nobody) Summary: test zipimport fails Initial Comment: Python 2.3b2 build on AIX 4.3.3 Have no clue since zlib and other modules built/tested fine. ./python Lib/test/test_zipimport.py testAFakeZlib (__main__.UncompressedZipImportTestCase) ... ERROR testBadMTime (__main__.UncompressedZipImportTestCase) ... ok testBadMagic (__main__.UncompressedZipImportTestCase) ... ok testBadMagic2 (__main__.UncompressedZipImportTestCase) ... ok testBoth (__main__.UncompressedZipImportTestCase) ... ok testDeepPackage (__main__.UncompressedZipImportTestCase) ... ok testEmptyPy (__main__.UncompressedZipImportTestCase) ... ok testGetData (__main__.UncompressedZipImportTestCase) ... ok testImporterAttr (__main__.UncompressedZipImportTestCase) ... ok testPackage (__main__.UncompressedZipImportTestCase) ... ok testPy (__main__.UncompressedZipImportTestCase) ... ok testPyc (__main__.UncompressedZipImportTestCase) ... ok testAFakeZlib (__main__.CompressedZipImportTestCase) ... ERROR testBadMTime (__main__.CompressedZipImportTestCase) ... ok testBadMagic (__main__.CompressedZipImportTestCase) ... ok testBadMagic2 (__main__.CompressedZipImportTestCase) ... ok testBoth (__main__.CompressedZipImportTestCase) ... ok testDeepPackage (__main__.CompressedZipImportTestCase) ... ok testEmptyPy (__main__.CompressedZipImportTestCase) ... ok testGetData (__main__.CompressedZipImportTestCase) ... ok testImporterAttr (__main__.CompressedZipImportTestCase) ... ok testPackage (__main__.CompressedZipImportTestCase) ... ok testPy (__main__.CompressedZipImportTestCase) ... ok testPyc (__main__.CompressedZipImportTestCase) ... ok ========================================== ============================ ERROR: testAFakeZlib (__main__.UncompressedZipImportTestCase) ------------------------------------------------------- --------------- Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 89, in testAFakeZlib self.doTest(".py", files, "zlib") File "Lib/test/test_zipimport.py", line 65, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ========================================== ============================ ERROR: testAFakeZlib (__main__.CompressedZipImportTestCase) ------------------------------------------------------- --------------- Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 89, in testAFakeZlib self.doTest(".py", files, "zlib") File "Lib/test/test_zipimport.py", line 65, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ------------------------------------------------------- --------------- Ran 24 tests in 0.692s FAILED (errors=2) Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 196, in ? test_main() File "Lib/test/test_zipimport.py", line 192, in test_main CompressedZipImportTestCase File "/fads/cn5a/csw/free/Python2.3b2/Lib/test/test_sup port.py", line 259, in run_unittest run_suite(suite, testclass) File "/fads/cn5a/csw/free/Python2.3b2/Lib/test/test_sup port.py", line 246, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765456&group_id=5470 From noreply@sourceforge.net Thu Jul 3 19:19:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 11:19:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-765456 ] test zipimport fails Message-ID: Bugs item #765456, was opened at 2003-07-03 12:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765456&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Robin Friedrich (robinf1) >Assigned to: Just van Rossum (jvr) Summary: test zipimport fails Initial Comment: Python 2.3b2 build on AIX 4.3.3 Have no clue since zlib and other modules built/tested fine. ./python Lib/test/test_zipimport.py testAFakeZlib (__main__.UncompressedZipImportTestCase) ... ERROR testBadMTime (__main__.UncompressedZipImportTestCase) ... ok testBadMagic (__main__.UncompressedZipImportTestCase) ... ok testBadMagic2 (__main__.UncompressedZipImportTestCase) ... ok testBoth (__main__.UncompressedZipImportTestCase) ... ok testDeepPackage (__main__.UncompressedZipImportTestCase) ... ok testEmptyPy (__main__.UncompressedZipImportTestCase) ... ok testGetData (__main__.UncompressedZipImportTestCase) ... ok testImporterAttr (__main__.UncompressedZipImportTestCase) ... ok testPackage (__main__.UncompressedZipImportTestCase) ... ok testPy (__main__.UncompressedZipImportTestCase) ... ok testPyc (__main__.UncompressedZipImportTestCase) ... ok testAFakeZlib (__main__.CompressedZipImportTestCase) ... ERROR testBadMTime (__main__.CompressedZipImportTestCase) ... ok testBadMagic (__main__.CompressedZipImportTestCase) ... ok testBadMagic2 (__main__.CompressedZipImportTestCase) ... ok testBoth (__main__.CompressedZipImportTestCase) ... ok testDeepPackage (__main__.CompressedZipImportTestCase) ... ok testEmptyPy (__main__.CompressedZipImportTestCase) ... ok testGetData (__main__.CompressedZipImportTestCase) ... ok testImporterAttr (__main__.CompressedZipImportTestCase) ... ok testPackage (__main__.CompressedZipImportTestCase) ... ok testPy (__main__.CompressedZipImportTestCase) ... ok testPyc (__main__.CompressedZipImportTestCase) ... ok ========================================== ============================ ERROR: testAFakeZlib (__main__.UncompressedZipImportTestCase) ------------------------------------------------------- --------------- Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 89, in testAFakeZlib self.doTest(".py", files, "zlib") File "Lib/test/test_zipimport.py", line 65, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ========================================== ============================ ERROR: testAFakeZlib (__main__.CompressedZipImportTestCase) ------------------------------------------------------- --------------- Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 89, in testAFakeZlib self.doTest(".py", files, "zlib") File "Lib/test/test_zipimport.py", line 65, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ------------------------------------------------------- --------------- Ran 24 tests in 0.692s FAILED (errors=2) Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 196, in ? test_main() File "Lib/test/test_zipimport.py", line 192, in test_main CompressedZipImportTestCase File "/fads/cn5a/csw/free/Python2.3b2/Lib/test/test_sup port.py", line 259, in run_unittest run_suite(suite, testclass) File "/fads/cn5a/csw/free/Python2.3b2/Lib/test/test_sup port.py", line 246, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-03 14:19 Message: Logged In: YES user_id=33168 Just, any ideas why get_file() doesn't exist? I'll start testing on the snake farm (AIX 4.3.1.0) and let you know if I find anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765456&group_id=5470 From noreply@sourceforge.net Thu Jul 3 20:15:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 12:15:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-765456 ] test zipimport fails Message-ID: Bugs item #765456, was opened at 2003-07-03 12:42 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765456&group_id=5470 Category: Build Group: Python 2.3 Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Robin Friedrich (robinf1) Assigned to: Just van Rossum (jvr) Summary: test zipimport fails Initial Comment: Python 2.3b2 build on AIX 4.3.3 Have no clue since zlib and other modules built/tested fine. ./python Lib/test/test_zipimport.py testAFakeZlib (__main__.UncompressedZipImportTestCase) ... ERROR testBadMTime (__main__.UncompressedZipImportTestCase) ... ok testBadMagic (__main__.UncompressedZipImportTestCase) ... ok testBadMagic2 (__main__.UncompressedZipImportTestCase) ... ok testBoth (__main__.UncompressedZipImportTestCase) ... ok testDeepPackage (__main__.UncompressedZipImportTestCase) ... ok testEmptyPy (__main__.UncompressedZipImportTestCase) ... ok testGetData (__main__.UncompressedZipImportTestCase) ... ok testImporterAttr (__main__.UncompressedZipImportTestCase) ... ok testPackage (__main__.UncompressedZipImportTestCase) ... ok testPy (__main__.UncompressedZipImportTestCase) ... ok testPyc (__main__.UncompressedZipImportTestCase) ... ok testAFakeZlib (__main__.CompressedZipImportTestCase) ... ERROR testBadMTime (__main__.CompressedZipImportTestCase) ... ok testBadMagic (__main__.CompressedZipImportTestCase) ... ok testBadMagic2 (__main__.CompressedZipImportTestCase) ... ok testBoth (__main__.CompressedZipImportTestCase) ... ok testDeepPackage (__main__.CompressedZipImportTestCase) ... ok testEmptyPy (__main__.CompressedZipImportTestCase) ... ok testGetData (__main__.CompressedZipImportTestCase) ... ok testImporterAttr (__main__.CompressedZipImportTestCase) ... ok testPackage (__main__.CompressedZipImportTestCase) ... ok testPy (__main__.CompressedZipImportTestCase) ... ok testPyc (__main__.CompressedZipImportTestCase) ... ok ========================================== ============================ ERROR: testAFakeZlib (__main__.UncompressedZipImportTestCase) ------------------------------------------------------- --------------- Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 89, in testAFakeZlib self.doTest(".py", files, "zlib") File "Lib/test/test_zipimport.py", line 65, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ========================================== ============================ ERROR: testAFakeZlib (__main__.CompressedZipImportTestCase) ------------------------------------------------------- --------------- Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 89, in testAFakeZlib self.doTest(".py", files, "zlib") File "Lib/test/test_zipimport.py", line 65, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ------------------------------------------------------- --------------- Ran 24 tests in 0.692s FAILED (errors=2) Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 196, in ? test_main() File "Lib/test/test_zipimport.py", line 192, in test_main CompressedZipImportTestCase File "/fads/cn5a/csw/free/Python2.3b2/Lib/test/test_sup port.py", line 259, in run_unittest run_suite(suite, testclass) File "/fads/cn5a/csw/free/Python2.3b2/Lib/test/test_sup port.py", line 246, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-03 15:15 Message: Logged In: YES user_id=33168 The test passes for me on AIX. Robin, did you build from a clean directory? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-03 14:19 Message: Logged In: YES user_id=33168 Just, any ideas why get_file() doesn't exist? I'll start testing on the snake farm (AIX 4.3.1.0) and let you know if I find anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765456&group_id=5470 From noreply@sourceforge.net Thu Jul 3 21:01:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 13:01:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-763047 ] test_strptime fails on Linux Message-ID: Bugs item #763047, was opened at 2003-06-30 00:33 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Dmitry Vasiliev (hdima) Assigned to: Brett Cannon (bcannon) Summary: test_strptime fails on Linux Initial Comment: Python 2.3b2+ (#1, Jun 30 2003, 10:50:39) Linux version 2.4.18-19.7asp test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 1 test failed: test_strptime ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-03 13:01 Message: Logged In: YES user_id=357491 OK, cleaned up a little and applied as rev 1.20 and 1.17 for Lib/ _strptime.py and Lib/test/test_strptime.py, repectively. Thanks to everyone who tested the fix. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-03 02:12 Message: Logged In: YES user_id=388573 Ok, tz_daylight.diff fixes the problem. ---------------------------------------------------------------------- Comment By: Paul Jarc (prjsf) Date: 2003-07-02 16:10 Message: Logged In: YES user_id=412110 I had the same problem; tz_daylight.diff indeed fixes it for me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-02 14:34 Message: Logged In: YES user_id=357491 OK, so I didn't need to completely restructure how timezones are handled (although I will for Python 2.4). The new patch adds a check to see if time.daylight is true or not to decide whether it should worry about duplicate values in time.tzname . ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:27 Message: Logged In: YES user_id=357491 I knew it. Okay, I know exactly what the issue is and I came up with a way to deal with it. Problem is that I need to completely restructure how timezones are handled to do it. But it will simplify the code and help remove special casing. Unfortunately I am going to be taking a rather long drive today so I won't get to this today (I think; I have been known to say this and make it turn out to be a lie =). But I will get it down this week and have a patch to test. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 03:41 Message: Logged In: YES user_id=388573 Python 2.3b2+ (#1, Jul 1 2003, 10:37:33) [GCC 2.96 20000731 (ASPLinux 7.3 2.96-112)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import time >>> time.tzname ('UTC', 'UTC') >>> time.daylight 0 >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:03 Message: Logged In: YES user_id=357491 What is time.tzname and time.daylight set for both of you guys? ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 02:32 Message: Logged In: YES user_id=388573 New patch produce new error: ----------------------------- test_strptime test test_strptime failed -- Traceback (most recent call last): File "/home/dima/src/other/python/dist/src/Lib/test/test_strptime.py", line 299, in test_timezone self.failUnlessEqual(strp_output.tm_isdst, 0) File "/home/dima/src/other/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: -1 != 0 1 test failed: test_strptime ------------------------------ Last time when I ran the test and it passed it was Python 2.3b1 (#1, Apr 28 2003, 11:09:08). ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 01:01 Message: Logged In: YES user_id=388573 Maybe it may helps: locale_time.timezone is ['UTC', 'GMT', 'UTC', ''] during testing ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 00:42 Message: Logged In: YES user_id=357491 Damn. OK, lets take Raymond's suggestion and try removing the time.tzset call. Try the new patch and let me know how it goes. Also, when was the last time you ran the test and it passed? I am trying to isolate if this is all happening because of my attempt to take time.daylight into account. ---------------------------------------------------------------------- Comment By: Dmitry Vasiliev (hdima) Date: 2003-07-01 00:25 Message: Logged In: YES user_id=388573 No, the same error remains ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 18:46 Message: Logged In: YES user_id=357491 So it wasn't what I thought it would be. But I do think I found the error. Dmitry, can you apply the patch that I attached to the report and see if it fixes the problem? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 16:43 Message: Logged In: YES user_id=357491 It is the same error and I am 99% sure I know the problem (stupid mistake on my part in the test). As soon as I am done recompiling I will fix it locally and see if it takes. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 05:04 Message: Logged In: YES user_id=89016 This might be a duplicate of 763052, which reported to same error under Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763047&group_id=5470 From noreply@sourceforge.net Thu Jul 3 21:02:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 13:02:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-763052 ] test_winsound, test_strptime fails in win2k Message-ID: Bugs item #763052, was opened at 2003-06-30 00:47 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Brett Cannon (bcannon) Summary: test_winsound, test_strptime fails in win2k Initial Comment: Hello, D:\apps\Python23>python -c "from test import test_winsound;test_winsound.test_ma in()" test_errors (test.test_winsound.BeepTest) ... ok test_extremes (test.test_winsound.BeepTest) ... ok test_increasingfrequency (test.test_winsound.BeepTest) ... ok test_asterisk (test.test_winsound.MessageBeepTest) ... ok test_default (test.test_winsound.MessageBeepTest) ... ok test_exclamation (test.test_winsound.MessageBeepTest) ... ok test_hand (test.test_winsound.MessageBeepTest) ... ok test_ok (test.test_winsound.MessageBeepTest) ... ok test_question (test.test_winsound.MessageBeepTest) ... ok test_alias_asterisk (test.test_winsound.PlaySoundTest) ... ok test_alias_exclamation (test.test_winsound.PlaySoundTest) ... ok test_alias_exit (test.test_winsound.PlaySoundTest) ... ok test_alias_fallback (test.test_winsound.PlaySoundTest) ... ok test_alias_hand (test.test_winsound.PlaySoundTest) ... ok test_alias_nofallback (test.test_winsound.PlaySoundTest) ... ok test_alias_question (test.test_winsound.PlaySoundTest) ... ok test_errors (test.test_winsound.PlaySoundTest) ... ok test_stopasync (test.test_winsound.PlaySoundTest) ... FAIL ====================================================================== FAIL: test_stopasync (test.test_winsound.PlaySoundTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------------------------------------------------- Ran 18 tests in 6.199s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_winsound.py", line 99, in test_main test_support.run_unittest(BeepTest, MessageBeepTest, PlaySoundTest) File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_winsound.py", line 94, in test_stopasync 'SystemQuestion', winsound.SND_ALIAS | winsound.SND_NOSTOP File "D:\apps\Python23\lib\unittest.py", line 285, in failUnlessRaises raise self.failureException, excName AssertionError: RuntimeError ---------------------------- D:\apps\Python23>python -c "from test import test_strptime; test_strptime.test_m ain()" test_am_pm (test.test_strptime.LocaleTime_Tests) ... ok test_by_hand_input (test.test_strptime.LocaleTime_Tests) ... ok test_date_time (test.test_strptime.LocaleTime_Tests) ... ok test_lang (test.test_strptime.LocaleTime_Tests) ... ok test_month (test.test_strptime.LocaleTime_Tests) ... ok test_timezone (test.test_strptime.LocaleTime_Tests) ... ok test_unknowntimezone (test.test_strptime.LocaleTime_Tests) ... ok test_weekday (test.test_strptime.LocaleTime_Tests) ... ok test_blankpattern (test.test_strptime.TimeRETests) ... ok test_compile (test.test_strptime.TimeRETests) ... ok test_getitem (test.test_strptime.TimeRETests) ... ok test_matching_with_escapes (test.test_strptime.TimeRETests) ... ok test_pattern (test.test_strptime.TimeRETests) ... ok test_pattern_escaping (test.test_strptime.TimeRETests) ... ok test_TypeError (test.test_strptime.StrptimeTests) ... ok test_caseinsensitive (test.test_strptime.StrptimeTests) ... ok test_date (test.test_strptime.StrptimeTests) ... ok test_date_time (test.test_strptime.StrptimeTests) ... ok test_day (test.test_strptime.StrptimeTests) ... ok test_defaults (test.test_strptime.StrptimeTests) ... ok test_hour (test.test_strptime.StrptimeTests) ... ok test_julian (test.test_strptime.StrptimeTests) ... ok test_minute (test.test_strptime.StrptimeTests) ... ok test_month (test.test_strptime.StrptimeTests) ... ok test_percent (test.test_strptime.StrptimeTests) ... ok test_second (test.test_strptime.StrptimeTests) ... ok test_time (test.test_strptime.StrptimeTests) ... ok test_timezone (test.test_strptime.StrptimeTests) ... FAIL test_unconverteddata (test.test_strptime.StrptimeTests) ... ok test_weekday (test.test_strptime.StrptimeTests) ... ok test_year (test.test_strptime.StrptimeTests) ... ok test_twelve_noon_midnight (test.test_strptime.Strptime12AMPMTests) ... ok test_all_julian_days (test.test_strptime.JulianTests) ... ok test_day_of_week_calculation (test.test_strptime.CalculationTests) ... ok test_gregorian_calculation (test.test_strptime.CalculationTests) ... ok test_julian_calculation (test.test_strptime.CalculationTests) ... ok ====================================================================== FAIL: test_timezone (test.test_strptime.StrptimeTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- Ran 36 tests in 0.330s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in ? File "D:\apps\Python23\lib\test\test_strptime.py", line 421, in test_main CalculationTests File "D:\apps\Python23\lib\test\test_support.py", line 259, in run_unittest run_suite(suite, testclass) File "D:\apps\Python23\lib\test\test_support.py", line 247, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "D:\apps\Python23\lib\test\test_strptime.py", line 312, in test_timezone "LocaleTime().timezone has duplicate values but " File "D:\apps\Python23\lib\unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: LocaleTime().timezone has duplicate values but timzone value not set to -1 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-03 13:02 Message: Logged In: YES user_id=357491 OK, the fix has been applied. Thanks for testing the fix. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-03 00:24 Message: Logged In: YES user_id=358087 Hello Brett, OK. Now it works. 10x. Miki ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-02 14:35 Message: Logged In: YES user_id=357491 The other bug report has a new patch to try out. Obviously let me know if it works. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:29 Message: Logged In: YES user_id=357491 I figured out the error in my code. I am going to rework it (pretty much completely rewrite the timezone handling code) and it should hopefully solve the problem. As I said in the other bug, I am going on a long drive today so I doubt I will get to it today but I will do my best to get to it by the end of the week to have a patch to test. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2003-07-01 07:18 Message: Logged In: YES user_id=35752 I get the same error (if I remember correctly) on W2K if I set the timezone to Eastern and disable the daylight saving time correction check box. I think this sets the TZ to EST (instead of the usual EDT). ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 04:36 Message: Logged In: YES user_id=358087 Hello Brett, >>> import time >>> time.tzname ('Jerusalem Standard Time', 'Jerusalem Standard Time') >>> time.daylight 0 >>> ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 03:09 Message: Logged In: YES user_id=357491 OK. I reponded in the other bug report asking both of you to tell me what time.tzname and time.daylight are set to. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-01 01:14 Message: Logged In: YES user_id=358087 Hello Brett, Sorry but no sigar (for both fixes). I'm attaching starck trace for both fixes. My time zone is GMT+2 (Jerusalem), and this is a laptop (IBM T30). Miki ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 18:49 Message: Logged In: YES user_id=357491 Miki, can you follow the test_strptime issues on bug #763047 ? It is the same problem and it will be easier to manage if you can follow along there. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 05:03 Message: Logged In: YES user_id=89016 The most likely reason for the winsound failure is, that your "SystemQuestion" sound has already finished before the second one starts, so there will be no RuntimeError exception. Checked in a fix as: Lib/test/test_winsound.py 1.6 Assigning to Brett Cannon for the strptime stuff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763052&group_id=5470 From noreply@sourceforge.net Thu Jul 3 21:59:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 13:59:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-765601 ] PackMan: per-user source install of Numeric Message-ID: Bugs item #765601, was opened at 2003-07-03 22: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=765601&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PackMan: per-user source install of Numeric Initial Comment: Doing a current user source install from numeric causes files to be skipped. This shoulnd't give an errror message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765601&group_id=5470 From noreply@sourceforge.net Thu Jul 3 22:08:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 14:08:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-765603 ] IDE has dirty sys.argv Message-ID: Bugs item #765603, was opened at 2003-07-03 23: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=765603&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: IDE has dirty sys.argv Initial Comment: The IDE has a dirty sys.argv, basically what the Finder gave it: >>> import sys >>> sys.argv ['/Applications/MacPython-2.3/PythonIDE.app/Contents/ Resources/PythonIDE.py', '-psn_0_4456449'] >>> This is unexpected to Python users and will make things that expect commandline argument (such as "import test.autotest") fail. The -psn option definitely has to go. Whether we keep sys.argv[0] I'm not sure. Assign back to me if you don't have time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765603&group_id=5470 From noreply@sourceforge.net Thu Jul 3 22:18:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 14:18:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-765608 ] Binary installer says it will take 0 bytes of diskspace Message-ID: Bugs item #765608, was opened at 2003-07-03 23:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765608&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Binary installer says it will take 0 bytes of diskspace Initial Comment: The installer says the installation will take zero bytes of diskspace. Rumour has it this is difficult to fix, but then the readme should warn about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765608&group_id=5470 From noreply@sourceforge.net Thu Jul 3 22:25:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 14:25:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-765615 ] Applet boot code overrides PYTHONPATH Message-ID: Bugs item #765615, was opened at 2003-07-03 23:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765615&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: Applet boot code overrides PYTHONPATH Initial Comment: The applet boot code generated by bundlebuilder overrides PYTHONPATH in stead of appending (prepending is probably better) to it. This means PYTHONPATH settings form .MacOSX/Environment.plist are overridden. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765615&group_id=5470 From noreply@sourceforge.net Thu Jul 3 22:34:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 14:34:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-765621 ] Packman crashes with garbage database Message-ID: Bugs item #765621, was opened at 2003-07-03 23: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=765621&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Packman crashes with garbage database Initial Comment: Packman crashes when you feed it a random HTML document, in stead of giving a decent error message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765621&group_id=5470 From noreply@sourceforge.net Thu Jul 3 22:42:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 14:42:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-765624 ] Cannot step in debugger if line # doesn't change Message-ID: Bugs item #765624, was opened at 2003-07-03 21: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=765624&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot step in debugger if line # doesn't change Initial Comment: The debugger trace function is not called with a line event if the line number executed doesn't change. This happens when an infinite looop containing a single line is executed, such as: while 1: print 1 A slightly more realistic example would be something like the following: items = range(0, 10) try: i = 0 while 1: print items[i]; i += 1 except IndexError: pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765624&group_id=5470 From noreply@sourceforge.net Thu Jul 3 23:05:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 15:05:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-765631 ] aix regression test failures on 2.3b2 Message-ID: Bugs item #765631, was opened at 2003-07-03 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=765631&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark van der Veer (markvxyz) Assigned to: Nobody/Anonymous (nobody) Summary: aix regression test failures on 2.3b2 Initial Comment: The following failures are from regrtest.py. Python was built from the 2.3b2 tarball using vac 6 on an aix 5.1 machine. test_coercion test test_coercion produced unexpected output: ****************************************** **************************** *** mismatch between lines 44-45 of expected output and lines 44-45 of actual output: - 2 / (2+0j) = (1+0j) ? ^ + 2 / (2+0j) = (1-0j) ? ^ - 2 /= (2+0j) => (1+0j) ? ^ + 2 /= (2+0j) => (1-0j) ? ^ *** mismatch between lines 152-153 of expected output and lines 152-153 of actual output: - 4.0 / (2+0j) = (2+0j) ? ^ + 4.0 / (2+0j) = (2-0j) ? ^ - 4.0 /= (2+0j) => (2+0j) ? ^ + 4.0 /= (2+0j) => (2-0j) ? ^ *** mismatch between lines 260-261 of expected output and lines 260-261 of actual output: - 2 / (2+0j) = (1+0j) ? ^ + 2 / (2+0j) = (1-0j) ? ^ - 2 /= (2+0j) => (1+0j) ? ^ + 2 /= (2+0j) => (1-0j) ? ^ *** mismatch between lines 332-333 of expected output and lines 332-333 of actual output: - (2+0j) / 2 = (1+0j) ? ^ + (2+0j) / 2 = (1-0j) ? ^ - (2+0j) /= 2 => (1+0j) ? ^ + (2+0j) /= 2 => (1-0j) ? ^ *** mismatch between lines 344-345 of expected output and lines 344-345 of actual output: - (2+0j) / 4.0 = (0.5+0j) ? ^ + (2+0j) / 4.0 = (0.5-0j) ? ^ - (2+0j) /= 4.0 => (0.5+0j) ? ^ + (2+0j) /= 4.0 => (0.5-0j) ? ^ *** mismatch between lines 356-357 of expected output and lines 356-357 of actual output: - (2+0j) / 2 = (1+0j) ? ^ + (2+0j) / 2 = (1-0j) ? ^ - (2+0j) /= 2 => (1+0j) ? ^ + (2+0j) /= 2 => (1-0j) ? ^ *** mismatch between lines 368-369 of expected output and lines 368-369 of actual output: - (2+0j) / (2+0j) = (1+0j) ? ^ + (2+0j) / (2+0j) = (1-0j) ? ^ - (2+0j) /= (2+0j) => (1+0j) ? ^ + (2+0j) /= (2+0j) => (1-0j) ? ^ *** mismatch between lines 416-417 of expected output and lines 416-417 of actual output: - (2+0j) / = (2+0j) ? ^ + (2+0j) / = (2-0j) ? ^ - (2+0j) /= => (2+0j) ? ^ + (2+0j) /= => (2-0j) ? ^ *** mismatch between lines 428-429 of expected output and lines 428-429 of actual output: - (2+0j) / = (1+0j) ? ^ + (2+0j) / = (1-0j) ? ^ - (2+0j) /= => (1+0j) ? ^ + (2+0j) /= => (1-0j) ? ^ *** mismatch between lines 800-801 of expected output and lines 800-801 of actual output: - / (2+0j) = (0.5+0j) ? ^ + / (2+0j) = (0.5-0j) ? ^ - /= (2+0j) => (0.5+0j) ? ^ + /= (2+0j) => (0.5-0j) ? ^ *** mismatch between lines 908-909 of expected output and lines 908-909 of actual output: - / (2+0j) = (1+0j) ? ^ + / (2+0j) = (1-0j) ? ^ - /= (2+0j) => (1+0j) ? ^ + /= (2+0j) => (1-0j) ? ^ ****************************************** **************************** test_commands test_posix test_posixpath test test_posixpath failed -- Traceback (most recent call last): File "/usr/local/lib/python2.3/test/test_posixpath.py", line 343, in test_expanduser posixpath.expanduser("~/") File "/usr/local/lib/python2.3/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: '//' != '/' test_repr test_resource test test_resource produced unexpected output: ****************************************** **************************** *** mismatch between line 2 of expected output and line 2 of actual output: - True + False ****************************************** **************************** ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765631&group_id=5470 From noreply@sourceforge.net Fri Jul 4 00:14:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 03 Jul 2003 16:14:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-765621 ] Packman crashes with garbage database Message-ID: Bugs item #765621, was opened at 2003-07-03 14:34 Message generated for change (Comment added) made by reowen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765621&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Packman crashes with garbage database Initial Comment: Packman crashes when you feed it a random HTML document, in stead of giving a decent error message. ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-07-03 16:14 Message: Logged In: YES user_id=431773 The 2.3b2-2 installer may have improved this some (I'm not sure). Most incorrect URLs I tried gave a nice explanatory error message. However, the url "http://python.org/packman" reliably gives a traceback. Here's an example: ExpatError: syntax error: line 1, column 62 File "Wapplication.py", line 45, in mainloop self.do1event(mask, wait) File "FrameWork.py", line 194, in do1event self.dispatch(event) File "FrameWork.py", line 227, in dispatch handler(event) File "FrameWork.py", line 289, in do_mouseDown handler(partcode, wid, event) File "Wapplication.py", line 203, in do_inMenuBar self.do_rawmenu(id, item, window, event) File "FrameWork.py", line 314, in do_rawmenu self.do_menu(id, item, window, event) File "FrameWork.py", line 321, in do_menu self.menubar.dispatch(id, item, window, event) File "Wapplication.py", line 445, in dispatch self.menus[id].dispatch(id, item, window, event) File "Wapplication.py", line 462, in dispatch W.CallbackCall(callback, 0, id, item, window, event) File "Wbase.py", line 684, in CallbackCall return callback() File "PackageManager.py", line 176, in domenu_openURL self.opendoc(url) File "PackageManager.py", line 150, in opendoc PackageBrowser(url) File "PackageManager.py", line 328, in __init__ messages = self.setuppimp(url) File "PackageManager.py", line 251, in setuppimp self.pimpdb.appendURL(url) File "pimp.py", line 259, in appendURL dict = plistlib.Plist.fromFile(fp) File "plistlib.py", line 211, in fromFile plist = p.parse(pathOrFile) File "plistlib.py", line 302, in parse parser.ParseFile(file) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765621&group_id=5470 From noreply@sourceforge.net Fri Jul 4 08:32:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 00:32:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-765456 ] test zipimport fails Message-ID: Bugs item #765456, was opened at 2003-07-03 18:42 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765456&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Robin Friedrich (robinf1) Assigned to: Just van Rossum (jvr) Summary: test zipimport fails Initial Comment: Python 2.3b2 build on AIX 4.3.3 Have no clue since zlib and other modules built/tested fine. ./python Lib/test/test_zipimport.py testAFakeZlib (__main__.UncompressedZipImportTestCase) ... ERROR testBadMTime (__main__.UncompressedZipImportTestCase) ... ok testBadMagic (__main__.UncompressedZipImportTestCase) ... ok testBadMagic2 (__main__.UncompressedZipImportTestCase) ... ok testBoth (__main__.UncompressedZipImportTestCase) ... ok testDeepPackage (__main__.UncompressedZipImportTestCase) ... ok testEmptyPy (__main__.UncompressedZipImportTestCase) ... ok testGetData (__main__.UncompressedZipImportTestCase) ... ok testImporterAttr (__main__.UncompressedZipImportTestCase) ... ok testPackage (__main__.UncompressedZipImportTestCase) ... ok testPy (__main__.UncompressedZipImportTestCase) ... ok testPyc (__main__.UncompressedZipImportTestCase) ... ok testAFakeZlib (__main__.CompressedZipImportTestCase) ... ERROR testBadMTime (__main__.CompressedZipImportTestCase) ... ok testBadMagic (__main__.CompressedZipImportTestCase) ... ok testBadMagic2 (__main__.CompressedZipImportTestCase) ... ok testBoth (__main__.CompressedZipImportTestCase) ... ok testDeepPackage (__main__.CompressedZipImportTestCase) ... ok testEmptyPy (__main__.CompressedZipImportTestCase) ... ok testGetData (__main__.CompressedZipImportTestCase) ... ok testImporterAttr (__main__.CompressedZipImportTestCase) ... ok testPackage (__main__.CompressedZipImportTestCase) ... ok testPy (__main__.CompressedZipImportTestCase) ... ok testPyc (__main__.CompressedZipImportTestCase) ... ok ========================================== ============================ ERROR: testAFakeZlib (__main__.UncompressedZipImportTestCase) ------------------------------------------------------- --------------- Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 89, in testAFakeZlib self.doTest(".py", files, "zlib") File "Lib/test/test_zipimport.py", line 65, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ========================================== ============================ ERROR: testAFakeZlib (__main__.CompressedZipImportTestCase) ------------------------------------------------------- --------------- Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 89, in testAFakeZlib self.doTest(".py", files, "zlib") File "Lib/test/test_zipimport.py", line 65, in doTest file = mod.get_file() AttributeError: 'module' object has no attribute 'get_file' ------------------------------------------------------- --------------- Ran 24 tests in 0.692s FAILED (errors=2) Traceback (most recent call last): File "Lib/test/test_zipimport.py", line 196, in ? test_main() File "Lib/test/test_zipimport.py", line 192, in test_main CompressedZipImportTestCase File "/fads/cn5a/csw/free/Python2.3b2/Lib/test/test_sup port.py", line 259, in run_unittest run_suite(suite, testclass) File "/fads/cn5a/csw/free/Python2.3b2/Lib/test/test_sup port.py", line 246, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-04 09:32 Message: Logged In: YES user_id=92689 get_file() not existing might be a symptom of a module existing with a name as used in the test suite, eg. "ziptestmodule". Since the error occurs in a nested package this seems very unlikely. Maybe running test_zipimport.py with -v can help to debug the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-03 21:15 Message: Logged In: YES user_id=33168 The test passes for me on AIX. Robin, did you build from a clean directory? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-03 20:19 Message: Logged In: YES user_id=33168 Just, any ideas why get_file() doesn't exist? I'll start testing on the snake farm (AIX 4.3.1.0) and let you know if I find anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765456&group_id=5470 From noreply@sourceforge.net Fri Jul 4 08:43:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 00:43:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-765615 ] Applet boot code overrides PYTHONPATH Message-ID: Bugs item #765615, was opened at 2003-07-03 23:25 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765615&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: Applet boot code overrides PYTHONPATH Initial Comment: The applet boot code generated by bundlebuilder overrides PYTHONPATH in stead of appending (prepending is probably better) to it. This means PYTHONPATH settings form .MacOSX/Environment.plist are overridden. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-04 09:43 Message: Logged In: YES user_id=92689 I've attached an untested patch. It's not entirely trivial (in that it's not a one-line change) as for standalone apps it must *not* use any existing PYTHONPATH. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765615&group_id=5470 From noreply@sourceforge.net Fri Jul 4 10:07:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 02:07:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-765822 ] os.setgroups missing in python2.3 Message-ID: Bugs item #765822, was opened at 2003-07-04 09: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=765822&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: os.setgroups missing in python2.3 Initial Comment: [forwarded from http://bugs.debian.org/199839] os.setgroups is still found in the docs. : tfheen@yiwaz ~ > python2.2 Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups >>> : tfheen@yiwaz ~ > python2.3 Python 2.3b2 (#2, Jun 30 2003, 10:50:53) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'setgroups' >>> Any good reason why it's removed, or has it been moved? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765822&group_id=5470 From noreply@sourceforge.net Fri Jul 4 10:04:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 02:04:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-765819 ] unable to specify another compiler Message-ID: Bugs item #765819, was opened at 2003-07-04 09: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=765819&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: unable to specify another compiler Initial Comment: [forwarded from http://bugs.debian.org/197537] Assume, python was built using `gcc' (version 3.3), but an extension module needs to be built using `gcc-2.95', because the library it depends on is still built by g++-2.95, which has another ABI than g++-3.3. I'm unable (or fail to see how) I can overwrite the compiler used by distutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765819&group_id=5470 From noreply@sourceforge.net Fri Jul 4 10:55:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 02:55:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-765842 ] os.setgroups missing in python2.3 Message-ID: Bugs item #765842, was opened at 2003-07-04 09: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=765842&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: os.setgroups missing in python2.3 Initial Comment: [forwarded from http://bugs.debian.org/199839] os.setgroups is still found in the docs. : tfheen@yiwaz ~ > python2.2 Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups >>> : tfheen@yiwaz ~ > python2.3 Python 2.3b2 (#2, Jun 30 2003, 10:50:53) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'setgroups' >>> Any good reason why it's removed, or has it been moved? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765842&group_id=5470 From noreply@sourceforge.net Fri Jul 4 11:33:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 03:33:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-765822 ] os.setgroups missing in python2.3 Message-ID: Bugs item #765822, was opened at 2003-07-04 09:07 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765822&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: os.setgroups missing in python2.3 Initial Comment: [forwarded from http://bugs.debian.org/199839] os.setgroups is still found in the docs. : tfheen@yiwaz ~ > python2.2 Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups >>> : tfheen@yiwaz ~ > python2.3 Python 2.3b2 (#2, Jun 30 2003, 10:50:53) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'setgroups' >>> Any good reason why it's removed, or has it been moved? ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-07-04 10:33 Message: Logged In: YES user_id=60903 strange. the conftest.c fails at configure time, because it needs the grp.h header, but only the unistd.h header gets included in the test. the configure test in python2.2 succeeds on the same (glibc-2.3.1) system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765822&group_id=5470 From noreply@sourceforge.net Fri Jul 4 11:34:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 03:34:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-765842 ] os.setgroups missing in python2.3 Message-ID: Bugs item #765842, was opened at 2003-07-04 09:55 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765842&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open >Resolution: Duplicate Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: os.setgroups missing in python2.3 Initial Comment: [forwarded from http://bugs.debian.org/199839] os.setgroups is still found in the docs. : tfheen@yiwaz ~ > python2.2 Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups >>> : tfheen@yiwaz ~ > python2.3 Python 2.3b2 (#2, Jun 30 2003, 10:50:53) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'setgroups' >>> Any good reason why it's removed, or has it been moved? ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-07-04 10:34 Message: Logged In: YES user_id=60903 duplicate of 765822 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765842&group_id=5470 From noreply@sourceforge.net Fri Jul 4 11:34:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 03:34:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-765842 ] os.setgroups missing in python2.3 Message-ID: Bugs item #765842, was opened at 2003-07-04 09:55 Message generated for change (Settings changed) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765842&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: os.setgroups missing in python2.3 Initial Comment: [forwarded from http://bugs.debian.org/199839] os.setgroups is still found in the docs. : tfheen@yiwaz ~ > python2.2 Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups >>> : tfheen@yiwaz ~ > python2.3 Python 2.3b2 (#2, Jun 30 2003, 10:50:53) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'setgroups' >>> Any good reason why it's removed, or has it been moved? ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-07-04 10:34 Message: Logged In: YES user_id=60903 duplicate of 765822 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765842&group_id=5470 From noreply@sourceforge.net Fri Jul 4 12:43:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 04:43:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-765888 ] InfoPlist.strings files are UTF-16. Message-ID: Bugs item #765888, was opened at 2003-07-04 13:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765888&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: InfoPlist.strings files are UTF-16. Initial Comment: Comment by Edward Moy: 6) Python.framework/Versions/2.3/Resources/English.lproj/ InfoPlist.strings and Python.app/Contents/Resources/ English.lproj/InfoPlist.strings needs to be UTF-16. This needs to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765888&group_id=5470 From noreply@sourceforge.net Fri Jul 4 13:11:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 05:11:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-765903 ] bundlebuilder Info.plist files. Message-ID: Bugs item #765903, was opened at 2003-07-04 14: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=765903&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: bundlebuilder Info.plist files. Initial Comment: Spotted by Edward Moy: ----------- 8) In BuildApplet.app/Contents/Info.plist, the CFBundleIdentifier needs to be a reverse-dns format (org.python.BuildApplet; in the WWDC preview, I have accidentally made it com.apple.BuildApplet). It also needs a CFBundleShortVersionString entry (I just used 1.0 for the WWDC preview). ------------ This needs a couple of changes, really: - bundlebuilder needs a way to specify these, plus sensible defaults. - the same for BuildApplet, when it calls bundlebuilder - Mac/OSX/Makefile needs to be adapted to use the new options. If you don't have the time to fix all of these please go as far as you can and reassign back to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470 From noreply@sourceforge.net Fri Jul 4 14:28:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 06:28:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-765903 ] bundlebuilder Info.plist files. Message-ID: Bugs item #765903, was opened at 2003-07-04 14:11 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: bundlebuilder Info.plist files. Initial Comment: Spotted by Edward Moy: ----------- 8) In BuildApplet.app/Contents/Info.plist, the CFBundleIdentifier needs to be a reverse-dns format (org.python.BuildApplet; in the WWDC preview, I have accidentally made it com.apple.BuildApplet). It also needs a CFBundleShortVersionString entry (I just used 1.0 for the WWDC preview). ------------ This needs a couple of changes, really: - bundlebuilder needs a way to specify these, plus sensible defaults. - the same for BuildApplet, when it calls bundlebuilder - Mac/OSX/Makefile needs to be adapted to use the new options. If you don't have the time to fix all of these please go as far as you can and reassign back to me. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-04 15:28 Message: Logged In: YES user_id=92689 IMO the sensible default is what we have now (and what a _lot_ of commercial apps do as well, just have a look at ~/Library/ Preferences/*.plist). For the applets shipping with Python it would indeed be much better if the bundle id started with "org.python.". I suggest to add a --bundle-identifier switch (and a bundle_identifier kwarg). I will do this unless you disagree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470 From noreply@sourceforge.net Fri Jul 4 15:21:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 07:21:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-765615 ] Applet boot code overrides PYTHONPATH Message-ID: Bugs item #765615, was opened at 2003-07-03 23:25 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765615&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: Applet boot code overrides PYTHONPATH Initial Comment: The applet boot code generated by bundlebuilder overrides PYTHONPATH in stead of appending (prepending is probably better) to it. This means PYTHONPATH settings form .MacOSX/Environment.plist are overridden. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-04 16:21 Message: Logged In: YES user_id=92689 Checked in. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-04 09:43 Message: Logged In: YES user_id=92689 I've attached an untested patch. It's not entirely trivial (in that it's not a one-line change) as for standalone apps it must *not* use any existing PYTHONPATH. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765615&group_id=5470 From noreply@sourceforge.net Fri Jul 4 15:22:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 07:22:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-765903 ] bundlebuilder Info.plist files. Message-ID: Bugs item #765903, was opened at 2003-07-04 14:11 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: bundlebuilder Info.plist files. Initial Comment: Spotted by Edward Moy: ----------- 8) In BuildApplet.app/Contents/Info.plist, the CFBundleIdentifier needs to be a reverse-dns format (org.python.BuildApplet; in the WWDC preview, I have accidentally made it com.apple.BuildApplet). It also needs a CFBundleShortVersionString entry (I just used 1.0 for the WWDC preview). ------------ This needs a couple of changes, really: - bundlebuilder needs a way to specify these, plus sensible defaults. - the same for BuildApplet, when it calls bundlebuilder - Mac/OSX/Makefile needs to be adapted to use the new options. If you don't have the time to fix all of these please go as far as you can and reassign back to me. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-04 16:22 Message: Logged In: YES user_id=92689 Done, except they're named bundle_id and --bundle-id. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-04 15:28 Message: Logged In: YES user_id=92689 IMO the sensible default is what we have now (and what a _lot_ of commercial apps do as well, just have a look at ~/Library/ Preferences/*.plist). For the applets shipping with Python it would indeed be much better if the bundle id started with "org.python.". I suggest to add a --bundle-identifier switch (and a bundle_identifier kwarg). I will do this unless you disagree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470 From noreply@sourceforge.net Fri Jul 4 16:29:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 08:29:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-765903 ] bundlebuilder Info.plist files. Message-ID: Bugs item #765903, was opened at 2003-07-04 14:11 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470 Category: Macintosh Group: None >Status: Open Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: bundlebuilder Info.plist files. Initial Comment: Spotted by Edward Moy: ----------- 8) In BuildApplet.app/Contents/Info.plist, the CFBundleIdentifier needs to be a reverse-dns format (org.python.BuildApplet; in the WWDC preview, I have accidentally made it com.apple.BuildApplet). It also needs a CFBundleShortVersionString entry (I just used 1.0 for the WWDC preview). ------------ This needs a couple of changes, really: - bundlebuilder needs a way to specify these, plus sensible defaults. - the same for BuildApplet, when it calls bundlebuilder - Mac/OSX/Makefile needs to be adapted to use the new options. If you don't have the time to fix all of these please go as far as you can and reassign back to me. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-04 17:29 Message: Logged In: YES user_id=45365 I got the impression that you only did step 1 (bundlebuilder), not BuildApplet and Mac/OSX/Makefile, right? Also, did you do the CFBundleShortVersionString bit too? Again, reassign to me if you don't feel like hacking this. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-04 16:22 Message: Logged In: YES user_id=92689 Done, except they're named bundle_id and --bundle-id. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-04 15:28 Message: Logged In: YES user_id=92689 IMO the sensible default is what we have now (and what a _lot_ of commercial apps do as well, just have a look at ~/Library/ Preferences/*.plist). For the applets shipping with Python it would indeed be much better if the bundle id started with "org.python.". I suggest to add a --bundle-identifier switch (and a bundle_identifier kwarg). I will do this unless you disagree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470 From noreply@sourceforge.net Fri Jul 4 17:24:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 09:24:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-765903 ] bundlebuilder Info.plist files. Message-ID: Bugs item #765903, was opened at 2003-07-04 14:11 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: bundlebuilder Info.plist files. Initial Comment: Spotted by Edward Moy: ----------- 8) In BuildApplet.app/Contents/Info.plist, the CFBundleIdentifier needs to be a reverse-dns format (org.python.BuildApplet; in the WWDC preview, I have accidentally made it com.apple.BuildApplet). It also needs a CFBundleShortVersionString entry (I just used 1.0 for the WWDC preview). ------------ This needs a couple of changes, really: - bundlebuilder needs a way to specify these, plus sensible defaults. - the same for BuildApplet, when it calls bundlebuilder - Mac/OSX/Makefile needs to be adapted to use the new options. If you don't have the time to fix all of these please go as far as you can and reassign back to me. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-04 18:24 Message: Logged In: YES user_id=92689 Oops, you're right, I was too fast: I indeed didn't do BuildApplet or CFBundleShortVersionString. I'm worried about bundlebuilder feature-bloat, though: the net -- bundle-id flag is only a convenience to avoid creating an explicit plist. BuildApplet could easily create the plist "manually", and that would in fact be the more general solution, so I'm tempted to rip --bundle-id out again. Do all bundles *have* to specify CFBundleShortVersionString? If so, should bundlebuilder simply use "1.0" if it's not specified in the plist? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-04 17:29 Message: Logged In: YES user_id=45365 I got the impression that you only did step 1 (bundlebuilder), not BuildApplet and Mac/OSX/Makefile, right? Also, did you do the CFBundleShortVersionString bit too? Again, reassign to me if you don't feel like hacking this. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-04 16:22 Message: Logged In: YES user_id=92689 Done, except they're named bundle_id and --bundle-id. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-04 15:28 Message: Logged In: YES user_id=92689 IMO the sensible default is what we have now (and what a _lot_ of commercial apps do as well, just have a look at ~/Library/ Preferences/*.plist). For the applets shipping with Python it would indeed be much better if the bundle id started with "org.python.". I suggest to add a --bundle-identifier switch (and a bundle_identifier kwarg). I will do this unless you disagree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470 From noreply@sourceforge.net Sat Jul 5 00:33:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 16:33:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-766210 ] Mac/OSX/Makefile assumes case-insensitive build Message-ID: Bugs item #766210, was opened at 2003-07-05 01:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766210&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Mac/OSX/Makefile assumes case-insensitive build Initial Comment: Mac/OSX/Makefile doesn't work on a case-sensitive filesystem, because it assumes that python.exe exists. Here's a fragment of an email conversation on the topic: ---------------- 1) In the top level Makefile, BUILDEXE is set depending on whether the filesystem is case insensitive or not. However, Mac/OSX/Makefile always assumes case-insensitivity, so there can be a conflict if python is built under Mac OS X on UFS or NFS. This is unintentional. But: I don't have a UFS file system handy right now, and visual inspection of Mac/OSX/Makefile hasn't revealed any obvious things. Could you elaborate? If all else fails send me the diff, after going through the release process. Sorry I wasn't more clear. It is the following line in Mac/ OSX/Makefile that is the problem: BUILDPYTHON=$(builddir)/python.exe This expects the top level Makefile to have added a .exe suffix, which would only happen if a case-insensitive filesystem was detected. -------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766210&group_id=5470 From noreply@sourceforge.net Sat Jul 5 05:14:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 04 Jul 2003 21:14:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-766238 ] platform.py bug fix for Java Message-ID: Bugs item #766238, was opened at 2003-07-05 04:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766238&group_id=5470 Category: Extension Modules Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: J. Shane (yosher) Assigned to: Nobody/Anonymous (nobody) Summary: platform.py bug fix for Java Initial Comment: # This module is maintained by Marc-Andre Lemburg . # If you find problems, please submit bug reports/patches via the # Python SourceForge Project Page and assign them to "lemburg". I believe that def _java_getprop(self,name,default): needs to be changed to def _java_getprop(name,default): for platform.py to work for the Java Environment. I was getting the error message: Traceback (innermost last): File "platform.py", line 1233, in ? File "platform.py", line 1167, in platform File "platform.py", line 954, in uname File "platform.py", line 614, in java_ver TypeError: _java_getprop() takes at least 3 arguments (2 given) When I deleted "self," from the def, I get Java-1.4.1_02-Java_HotSpot-TM-_Client_VM,_1.4.1_02- b06,_Sun_Microsystems_Inc. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766238&group_id=5470 From noreply@sourceforge.net Sat Jul 5 08:14:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 00:14:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-715782 ] pydoc support for keywords Message-ID: Bugs item #715782, was opened at 2003-04-05 11:36 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715782&group_id=5470 Category: Documentation Group: Feature Request Status: Closed Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc support for keywords Initial Comment: [ from http://bugs.debian.org/186775 ] If one uses $ man perl one gets on a path that can lead one to eventually find docs for the most basic commands like 'while' However for python one sees one is to use pydoc. But running pydoc, one just sees pydoc - the Python documentation tool /usr/bin/pydoc ... etc. no hint about how to learn about basics like 'while'. BTW, I wish it would say pydoc, not /usr/bin/pydoc ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-07-05 07:14 Message: Logged In: YES user_id=60903 Is it intended, that 'pydoc while' displays the snippet from the reference manual, while searching in 'pydoc -g' doesn't find anything? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 09:08 Message: Logged In: YES user_id=21627 This is fixed in pydoc.py 1.85 NEWS 1.783 as far is Python proper is concerned. To get keyword help, the Python HTML documentation must be found in the locations in which it is searched for. The "I wish it would say pydoc" wish will not be granted. Printing the complete path is deliberate, so that users can see where in the path pydoc was found. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-04-24 14:29 Message: Logged In: YES user_id=31435 Unassigned (I can't make time for this). ---------------------------------------------------------------------- Comment By: Douglas Napoleone (derivin) Date: 2003-04-19 04:06 Message: Logged In: YES user_id=541557 Could you please include the OS, install, distro for python? the distrobution from ActiveState has a very detailed manpage on linux. The cygwin distrobution (currently hosted/maintained by RedHat) has a poor man page (similar yet different from your example). To be honest, I thought there was only a GNU info page, a quick find of the source tree didnt turn anything up, (but Im building on windows). ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2003-04-06 08:33 Message: Logged In: YES user_id=36166 It should suggest to run ``python`` and type ``help()``. Then one can type ``topics`` and access the language documentation itself, e.g. ``LOOPING`` would tell one that there is a ``while`` whose specific documentation is accessible by typing the ``while`` keyword itself. Also some sentences about the usefulness of the Python prompt, `dir()` and `help()` for learning might be in order... BTW, it would be more consistent if pydoc would support the special topics from the command line (it would require a non-ambiguos option to avoid shadowing modules in current directoy that happen to have one of the special name)... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715782&group_id=5470 From noreply@sourceforge.net Sat Jul 5 10:04:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 02:04:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-766288 ] property() example gives syntax error Message-ID: Bugs item #766288, was opened at 2003-07-05 11: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=766288&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: property() example gives syntax error Initial Comment: the last line of the builtin property() function documentation ("x = property...") is indented 8 chars instead of 4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766288&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:16:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:16:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-766238 ] platform.py bug fix for Java Message-ID: Bugs item #766238, was opened at 2003-07-05 00:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766238&group_id=5470 >Category: Python Library Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: J. Shane (yosher) >Assigned to: Neal Norwitz (nnorwitz) Summary: platform.py bug fix for Java Initial Comment: # This module is maintained by Marc-Andre Lemburg . # If you find problems, please submit bug reports/patches via the # Python SourceForge Project Page and assign them to "lemburg". I believe that def _java_getprop(self,name,default): needs to be changed to def _java_getprop(name,default): for platform.py to work for the Java Environment. I was getting the error message: Traceback (innermost last): File "platform.py", line 1233, in ? File "platform.py", line 1167, in platform File "platform.py", line 954, in uname File "platform.py", line 614, in java_ver TypeError: _java_getprop() takes at least 3 arguments (2 given) When I deleted "self," from the def, I get Java-1.4.1_02-Java_HotSpot-TM-_Client_VM,_1.4.1_02- b06,_Sun_Microsystems_Inc. Thanks! ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-05 12:16 Message: Logged In: YES user_id=33168 This fix has already been made. Thanks. It would be great if you could check out the version from CVS to test more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766238&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:19:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:19:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-765631 ] aix regression test failures on 2.3b2 Message-ID: Bugs item #765631, was opened at 2003-07-03 18:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765631&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Mark van der Veer (markvxyz) >Assigned to: Neal Norwitz (nnorwitz) Summary: aix regression test failures on 2.3b2 Initial Comment: The following failures are from regrtest.py. Python was built from the 2.3b2 tarball using vac 6 on an aix 5.1 machine. test_coercion test test_coercion produced unexpected output: ****************************************** **************************** *** mismatch between lines 44-45 of expected output and lines 44-45 of actual output: - 2 / (2+0j) = (1+0j) ? ^ + 2 / (2+0j) = (1-0j) ? ^ - 2 /= (2+0j) => (1+0j) ? ^ + 2 /= (2+0j) => (1-0j) ? ^ *** mismatch between lines 152-153 of expected output and lines 152-153 of actual output: - 4.0 / (2+0j) = (2+0j) ? ^ + 4.0 / (2+0j) = (2-0j) ? ^ - 4.0 /= (2+0j) => (2+0j) ? ^ + 4.0 /= (2+0j) => (2-0j) ? ^ *** mismatch between lines 260-261 of expected output and lines 260-261 of actual output: - 2 / (2+0j) = (1+0j) ? ^ + 2 / (2+0j) = (1-0j) ? ^ - 2 /= (2+0j) => (1+0j) ? ^ + 2 /= (2+0j) => (1-0j) ? ^ *** mismatch between lines 332-333 of expected output and lines 332-333 of actual output: - (2+0j) / 2 = (1+0j) ? ^ + (2+0j) / 2 = (1-0j) ? ^ - (2+0j) /= 2 => (1+0j) ? ^ + (2+0j) /= 2 => (1-0j) ? ^ *** mismatch between lines 344-345 of expected output and lines 344-345 of actual output: - (2+0j) / 4.0 = (0.5+0j) ? ^ + (2+0j) / 4.0 = (0.5-0j) ? ^ - (2+0j) /= 4.0 => (0.5+0j) ? ^ + (2+0j) /= 4.0 => (0.5-0j) ? ^ *** mismatch between lines 356-357 of expected output and lines 356-357 of actual output: - (2+0j) / 2 = (1+0j) ? ^ + (2+0j) / 2 = (1-0j) ? ^ - (2+0j) /= 2 => (1+0j) ? ^ + (2+0j) /= 2 => (1-0j) ? ^ *** mismatch between lines 368-369 of expected output and lines 368-369 of actual output: - (2+0j) / (2+0j) = (1+0j) ? ^ + (2+0j) / (2+0j) = (1-0j) ? ^ - (2+0j) /= (2+0j) => (1+0j) ? ^ + (2+0j) /= (2+0j) => (1-0j) ? ^ *** mismatch between lines 416-417 of expected output and lines 416-417 of actual output: - (2+0j) / = (2+0j) ? ^ + (2+0j) / = (2-0j) ? ^ - (2+0j) /= => (2+0j) ? ^ + (2+0j) /= => (2-0j) ? ^ *** mismatch between lines 428-429 of expected output and lines 428-429 of actual output: - (2+0j) / = (1+0j) ? ^ + (2+0j) / = (1-0j) ? ^ - (2+0j) /= => (1+0j) ? ^ + (2+0j) /= => (1-0j) ? ^ *** mismatch between lines 800-801 of expected output and lines 800-801 of actual output: - / (2+0j) = (0.5+0j) ? ^ + / (2+0j) = (0.5-0j) ? ^ - /= (2+0j) => (0.5+0j) ? ^ + /= (2+0j) => (0.5-0j) ? ^ *** mismatch between lines 908-909 of expected output and lines 908-909 of actual output: - / (2+0j) = (1+0j) ? ^ + / (2+0j) = (1-0j) ? ^ - /= (2+0j) => (1+0j) ? ^ + /= (2+0j) => (1-0j) ? ^ ****************************************** **************************** test_commands test_posix test_posixpath test test_posixpath failed -- Traceback (most recent call last): File "/usr/local/lib/python2.3/test/test_posixpath.py", line 343, in test_expanduser posixpath.expanduser("~/") File "/usr/local/lib/python2.3/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: '//' != '/' test_repr test_resource test test_resource produced unexpected output: ****************************************** **************************** *** mismatch between line 2 of expected output and line 2 of actual output: - True + False ****************************************** **************************** ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-05 12:19 Message: Logged In: YES user_id=33168 test_posixpath should have been fixed in CVS since 2.3b2. The problem occurred when running the tests as root. Please test the version from CVS. test_coercion is a duplicate of 678265 test_resource is a duplicate of 678264 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765631&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:21:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:21:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-765822 ] os.setgroups missing in python2.3 Message-ID: Bugs item #765822, was opened at 2003-07-04 05:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765822&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: os.setgroups missing in python2.3 Initial Comment: [forwarded from http://bugs.debian.org/199839] os.setgroups is still found in the docs. : tfheen@yiwaz ~ > python2.2 Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups >>> : tfheen@yiwaz ~ > python2.3 Python 2.3b2 (#2, Jun 30 2003, 10:50:53) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'setgroups' >>> Any good reason why it's removed, or has it been moved? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-05 12:21 Message: Logged In: YES user_id=33168 This fails for me on redhat 9 too. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-07-04 06:33 Message: Logged In: YES user_id=60903 strange. the conftest.c fails at configure time, because it needs the grp.h header, but only the unistd.h header gets included in the test. the configure test in python2.2 succeeds on the same (glibc-2.3.1) system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765822&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:25:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:25:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-765819 ] unable to specify another compiler Message-ID: Bugs item #765819, was opened at 2003-07-04 11:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765819&group_id=5470 Category: Distutils Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: unable to specify another compiler Initial Comment: [forwarded from http://bugs.debian.org/197537] Assume, python was built using `gcc' (version 3.3), but an extension module needs to be built using `gcc-2.95', because the library it depends on is still built by g++-2.95, which has another ABI than g++-3.3. I'm unable (or fail to see how) I can overwrite the compiler used by distutils. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:25 Message: Logged In: YES user_id=21627 This is not a bug. The C compiler can be replaced by either setting the CC/CXX environment variable, or by modifying distutils.sysconfig._config_vars. Notice that replacing the C compiler may result in an inoperable module, if mixing different compilers is not supported in the system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765819&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:27:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:27:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-765822 ] os.setgroups missing in python2.3 Message-ID: Bugs item #765822, was opened at 2003-07-04 11:07 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765822&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Martin v. Löwis (loewis) Summary: os.setgroups missing in python2.3 Initial Comment: [forwarded from http://bugs.debian.org/199839] os.setgroups is still found in the docs. : tfheen@yiwaz ~ > python2.2 Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups >>> : tfheen@yiwaz ~ > python2.3 Python 2.3b2 (#2, Jun 30 2003, 10:50:53) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'setgroups' >>> Any good reason why it's removed, or has it been moved? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-05 18:21 Message: Logged In: YES user_id=33168 This fails for me on redhat 9 too. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-07-04 12:33 Message: Logged In: YES user_id=60903 strange. the conftest.c fails at configure time, because it needs the grp.h header, but only the unistd.h header gets included in the test. the configure test in python2.2 succeeds on the same (glibc-2.3.1) system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765822&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:29:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:29:24 -0700 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 (Settings changed) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764839&group_id=5470 From noreply@sourceforge.net Sat Jul 5 17:32:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 09:32:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-764560 ] python treats IRIX64 and IRIX as different, but they are the Message-ID: Bugs item #764560, was opened at 2003-07-02 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=764560&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gordon Lack (gmlack) Assigned to: Nobody/Anonymous (nobody) Summary: python treats IRIX64 and IRIX as different, but they are the Initial Comment: Related to bug 216255 (116255?), but this goes deeper, as it refers to the *running* of python rather than just its building. If I build python on an Irix6.5 system (that is new/large) the tag "irix646" is used in the build/temp.* directory (and Lib/plat-*). This has several effects: a) the plat-irix6 directory from the standard distribution is ignored. b) running the tests on an IRIX system after compiling on an IRIX64 one causes it to rebuild everything, as it will look for temp.irix-6.5-2.2 and lib.irix-6.5-2.2 in build/ rather than the temp.irix64-6.5-2.2 and lib.irix64-6.5-2.2 which were actually built. c) running the same executable on a smaller system (a single installation, NFS mounted onto a large number of systems, for which "uname -s" returns IRIX, not IRIX64) will cause it to fail to find the </python2.2/Lib/plat-irix646 directory. (This might also affect 3rd party module installation?). IRIX and IRIX64 are the same when you build n32 binaries (which is what is built by default). Python should treat them the same. It should be possible to *configure* this OS tag at configure time (which would avoid this problem). Also, installing the "plat-irix646" directories under <> rather than <> would remove the need for such a tag in the installed files. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:32 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=105470&aid=764560&group_id=5470 From noreply@sourceforge.net Sat Jul 5 18:39:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 10:39:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-766288 ] property() example gives syntax error Message-ID: Bugs item #766288, was opened at 2003-07-05 05:04 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766288&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bastian Kleineidam (calvin) >Assigned to: Neal Norwitz (nnorwitz) Summary: property() example gives syntax error Initial Comment: the last line of the builtin property() function documentation ("x = property...") is indented 8 chars instead of 4. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-05 13:39 Message: Logged In: YES user_id=33168 Thanks! Checked in as: * Doc/lib/libfuncs.tex 1.143 and 1.100.4.17 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766288&group_id=5470 From noreply@sourceforge.net Sat Jul 5 20:25:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 12:25:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-765819 ] unable to specify another compiler Message-ID: Bugs item #765819, was opened at 2003-07-04 09:04 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765819&group_id=5470 Category: Distutils Group: Python 2.3 >Status: Open Resolution: Works For Me Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: unable to specify another compiler Initial Comment: [forwarded from http://bugs.debian.org/197537] Assume, python was built using `gcc' (version 3.3), but an extension module needs to be built using `gcc-2.95', because the library it depends on is still built by g++-2.95, which has another ABI than g++-3.3. I'm unable (or fail to see how) I can overwrite the compiler used by distutils. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-07-05 19:25 Message: Logged In: YES user_id=60903 Doesn't work for me. I can reproduce this at least for the python-apt package on Debian (apt-get source python-apt) CC=gcc-2.95 /usr/bin/python setup.py build gcc still gets used. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 16:25 Message: Logged In: YES user_id=21627 This is not a bug. The C compiler can be replaced by either setting the CC/CXX environment variable, or by modifying distutils.sysconfig._config_vars. Notice that replacing the C compiler may result in an inoperable module, if mixing different compilers is not supported in the system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765819&group_id=5470 From noreply@sourceforge.net Sun Jul 6 01:17:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 05 Jul 2003 17:17:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-766541 ] string.title() doesn't understand apostrophes Message-ID: Bugs item #766541, was opened at 2003-07-05 19:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766541&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steve Greenland (vmole) Assigned to: Nobody/Anonymous (nobody) Summary: string.title() doesn't understand apostrophes Initial Comment: Consider the following: steveg@speedy:~/jbox$ python Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "I've fallen and i can't get up".title() "I'Ve Fallen And I Can'T Get Up" >>> That looks fairly non-standard to me. Apparently, the title() method treats apostrophes as whitespace/word seperators/something. Thanks, Steve ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766541&group_id=5470 From noreply@sourceforge.net Sun Jul 6 08:59:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 00:59:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-763032 ] tut/contents.html does not exist Message-ID: Bugs item #763032, was opened at 2003-06-30 06:59 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Open Resolution: Fixed Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: tut/contents.html does not exist Initial Comment: 2.2.3 and 2.3: generating the html tutorial doesn't create tut/contents.html, although it's referenced by other tut/* pages. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-07-06 07:59 Message: Logged In: YES user_id=60903 I was wrong. The fix is in 2.3b2 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-01 13:44 Message: Logged In: YES user_id=3066 I don't see this. Can you tell me exactly which file you downloaded? The full filename and where you found it would both help. Also, the name of a file that contains the bogus link. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-30 22:01 Message: Logged In: YES user_id=3066 Re-opened so I won't forget to look at this later; hopefully tonight. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-06-30 21:09 Message: Logged In: YES user_id=60903 I'm confused. This is what I got from the 2.3b2 tarball ... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-30 17:13 Message: Logged In: YES user_id=3066 This was fixed in time for the Python 2.3 beta 2 release; please update your copy of the formatting tools. In particular, Doc/perl/l2hinit.perl needs to be updated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470 From noreply@sourceforge.net Sun Jul 6 10:30:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 02:30:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-765822 ] os.setgroups missing in python2.3 Message-ID: Bugs item #765822, was opened at 2003-07-04 11:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765822&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Martin v. Löwis (loewis) Summary: os.setgroups missing in python2.3 Initial Comment: [forwarded from http://bugs.debian.org/199839] os.setgroups is still found in the docs. : tfheen@yiwaz ~ > python2.2 Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups >>> : tfheen@yiwaz ~ > python2.3 Python 2.3b2 (#2, Jun 30 2003, 10:50:53) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.setgroups Traceback (most recent call last): File "", line 1, in ? AttributeError: 'module' object has no attribute 'setgroups' >>> Any good reason why it's removed, or has it been moved? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-06 11:30 Message: Logged In: YES user_id=21627 This is fixed in configure.in 1.422 configure 1.411 by including grp.h in the test. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-05 18:21 Message: Logged In: YES user_id=33168 This fails for me on redhat 9 too. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-07-04 12:33 Message: Logged In: YES user_id=60903 strange. the conftest.c fails at configure time, because it needs the grp.h header, but only the unistd.h header gets included in the test. the configure test in python2.2 succeeds on the same (glibc-2.3.1) system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765822&group_id=5470 From noreply@sourceforge.net Sun Jul 6 10:32:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 02:32:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-766541 ] string.title() doesn't understand apostrophes Message-ID: Bugs item #766541, was opened at 2003-07-06 02:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766541&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steve Greenland (vmole) Assigned to: Nobody/Anonymous (nobody) Summary: string.title() doesn't understand apostrophes Initial Comment: Consider the following: steveg@speedy:~/jbox$ python Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "I've fallen and i can't get up".title() "I'Ve Fallen And I Can'T Get Up" >>> That looks fairly non-standard to me. Apparently, the title() method treats apostrophes as whitespace/word seperators/something. Thanks, Steve ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-06 11:32 Message: Logged In: YES user_id=21627 Unfortunately, this usage of the apostrophe is specific to the English language. Martin says, 'if the apostrophe is used for indirect speech, upper-casing after it is correct'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766541&group_id=5470 From noreply@sourceforge.net Sun Jul 6 10:46:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 02:46:10 -0700 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-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@sourceforge.net Sun Jul 6 11:14:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 03:14:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-765819 ] unable to specify another compiler Message-ID: Bugs item #765819, was opened at 2003-07-04 11:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765819&group_id=5470 Category: Distutils >Group: Python 2.2.3 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: A.M. Kuchling (akuchling) Summary: unable to specify another compiler Initial Comment: [forwarded from http://bugs.debian.org/197537] Assume, python was built using `gcc' (version 3.3), but an extension module needs to be built using `gcc-2.95', because the library it depends on is still built by g++-2.95, which has another ABI than g++-3.3. I'm unable (or fail to see how) I can overwrite the compiler used by distutils. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-06 12:14 Message: Logged In: YES user_id=21627 Please try this with python2.3 instead. See Lib/distutils/sysconfig.py:customize_compiler. 2.3 has a block if os.environ.has_key('CC'): cc = os.environ['CC'] if os.environ.has_key('CXX'): cxx = os.environ['CXX'] which was added through patch #588809. Regrouping this as 2.2.3 issue. I'm assigning this to Andrew for consideration whether the patch should be backported. As this is, strictly speaking, a new feature, it might not be eligible for back-porting. Meanwhile, modifying setup.py to read from distutils.sysconfig import parse_makefile, get_config_vars config_vars = get_config_vars() config_vars['CC'] = 'gcc-2.95' employs the other approach of configuration. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-07-05 21:25 Message: Logged In: YES user_id=60903 Doesn't work for me. I can reproduce this at least for the python-apt package on Debian (apt-get source python-apt) CC=gcc-2.95 /usr/bin/python setup.py build gcc still gets used. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:25 Message: Logged In: YES user_id=21627 This is not a bug. The C compiler can be replaced by either setting the CC/CXX environment variable, or by modifying distutils.sysconfig._config_vars. Notice that replacing the C compiler may result in an inoperable module, if mixing different compilers is not supported in the system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765819&group_id=5470 From noreply@sourceforge.net Sun Jul 6 13:32:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 05:32:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 07: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=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kurt Grittner (grittkmg) Assigned to: Tim Peters (tim_one) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Sun Jul 6 15:04:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 07:04:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-766696 ] gcc-3.3: dereferencing type-punned pointer Message-ID: Bugs item #766696, was opened at 2003-07-06 14: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=766696&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: gcc-3.3: dereferencing type-punned pointer Initial Comment: Building with gcc-3.3 leads to about 250 warnings 263 dereferencing type-punned pointer will break strict-aliasing rules Include/intobject.h:#define Py_True ((PyObject *) &_Py_TrueStruct) although the test results look good. Please add -fno-strict-aliasing to the compiler flags, when compiling with gcc-3.3 or up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766696&group_id=5470 From noreply@sourceforge.net Sun Jul 6 16:53:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 08:53:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-766541 ] string.title() doesn't understand apostrophes Message-ID: Bugs item #766541, was opened at 2003-07-05 20:17 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766541&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steve Greenland (vmole) Assigned to: Nobody/Anonymous (nobody) Summary: string.title() doesn't understand apostrophes Initial Comment: Consider the following: steveg@speedy:~/jbox$ python Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "I've fallen and i can't get up".title() "I'Ve Fallen And I Can'T Get Up" >>> That looks fairly non-standard to me. Apparently, the title() method treats apostrophes as whitespace/word seperators/something. Thanks, Steve ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-07-06 11:53 Message: Logged In: YES user_id=593130 If the ' directly follows a letter, then it is being used for a contraction and not for indirect speech, and the following letter should not be uppercased. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-06 05:32 Message: Logged In: YES user_id=21627 Unfortunately, this usage of the apostrophe is specific to the English language. Martin says, 'if the apostrophe is used for indirect speech, upper-casing after it is correct'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766541&group_id=5470 From noreply@sourceforge.net Sun Jul 6 17:34:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 09:34:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 08:32 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kurt Grittner (grittkmg) >Assigned to: Nobody/Anonymous (nobody) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-06 12:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Sun Jul 6 19:41:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 11:41:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 07:32 Message generated for change (Comment added) made by grittkmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kurt Grittner (grittkmg) Assigned to: Nobody/Anonymous (nobody) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 13:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 11:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Sun Jul 6 21:57:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 13:57:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 07:32 Message generated for change (Comment added) made by grittkmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kurt Grittner (grittkmg) Assigned to: Nobody/Anonymous (nobody) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 15:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 13:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 11:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Sun Jul 6 22:42:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 14:42:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-766842 ] Installing documentation doesn't make it show up Message-ID: Bugs item #766842, was opened at 2003-07-06 23: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=766842&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Installing documentation doesn't make it show up Initial Comment: If you're installing the full Python documentation through Package Manager, but you've already run the IDE previously (the common case) the new documentation doesn't show up in the Apple Help Viewer. It does show up when you remove your help preferences. Probably a bug in the registration code in PythonIDE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766842&group_id=5470 From noreply@sourceforge.net Mon Jul 7 00:24:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 16:24:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-715063 ] bsddb.first()/next() raise undocumented exception Message-ID: Bugs item #715063, was opened at 2003-04-03 20:03 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Christian Stork (cst) >Assigned to: Gregory P. Smith (greg) Summary: bsddb.first()/next() raise undocumented exception Initial Comment: bsddb object's first() & next() methods raise an undocumented exception. Wouldn't returning None make much more sense? And shouldn't this be documented? Python 2.3a2+ (#2, Mar 21 2003, 22:13:05) [GCC 3.2.3 20030316 (Debian prerelease)] on linux2 >>> import bsddb >>> h.bsddb.hashopen("testdb") >>> h.first() ------------------------------------------------------------ Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/bsddb/__init__.py", line 134, in first rv = self.dbc.first() DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/ data pair found') Note: The same exception appeared for the equivalent dbhash methods. But I assume this should be fixed if this bug is fixed. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-07-06 16:24 Message: Logged In: YES user_id=413 i'm taking a look. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-07 15:46 Message: Logged In: YES user_id=12800 pybsddb has this option to return None from cursor.get() methods instead of raising DBNotFoundError. The DBEnv method set_get_returns_none() can be used to change the behavior, although the default is to return None. I agree that this is very handy! I suppose .first() and .last() should perhaps honor this config as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 From noreply@sourceforge.net Mon Jul 7 01:01:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 17:01:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-715063 ] bsddb.first()/next() raise undocumented exception Message-ID: Bugs item #715063, was opened at 2003-04-03 20:03 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Christian Stork (cst) Assigned to: Gregory P. Smith (greg) Summary: bsddb.first()/next() raise undocumented exception Initial Comment: bsddb object's first() & next() methods raise an undocumented exception. Wouldn't returning None make much more sense? And shouldn't this be documented? Python 2.3a2+ (#2, Mar 21 2003, 22:13:05) [GCC 3.2.3 20030316 (Debian prerelease)] on linux2 >>> import bsddb >>> h.bsddb.hashopen("testdb") >>> h.first() ------------------------------------------------------------ Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/bsddb/__init__.py", line 134, in first rv = self.dbc.first() DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/ data pair found') Note: The same exception appeared for the equivalent dbhash methods. But I assume this should be fixed if this bug is fixed. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-07-06 17:01 Message: Logged In: YES user_id=413 DBNotFoundError derives from KeyError. The old bsddb library also raised KeyError on first/last/next calls when there was no more data rather than returning None so that interface cannot be changed. (I agree, returning None would make more sense; but I can't break the old interface). The new pybsddb interface's DB and DBEnv set_get_returns_none method does allow you to control this behaviour. If you are using the old style bsddb interface then you do not have access to the DBEnv before the DB object is created (DB objects inherit the flag setting from the DBEnv when they are created) so you'll need to call set_get_returns_none on the DB object itself: import bsddb # python 2.3 bsddb (aka bsddb3 or pybsddb) hdb = bsddb.hashopen("myhash", 'c') hdb.db.set_get_returns_none(1) # will only work on python 2.3 / pybsddb spam = hdb.first() while spam: spam = hdb.next() # notice there were no errors. I've looked at the code for first/last/prev/get and they all use the same internal DBCursor_get wrapper that obeys the set_get_returns_none flag so that you can write simple "foo = hdb.first(); while not foo: foo = hdb.next()" code. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 16:24 Message: Logged In: YES user_id=413 i'm taking a look. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-07 15:46 Message: Logged In: YES user_id=12800 pybsddb has this option to return None from cursor.get() methods instead of raising DBNotFoundError. The DBEnv method set_get_returns_none() can be used to change the behavior, although the default is to return None. I agree that this is very handy! I suppose .first() and .last() should perhaps honor this config as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 From noreply@sourceforge.net Mon Jul 7 01:35:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 17:35:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-766891 ] oct() function does not represent zero correctly Message-ID: Bugs item #766891, was opened at 2003-07-06 17:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766891&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joshua Biagio (roehnan) Assigned to: Nobody/Anonymous (nobody) Summary: oct() function does not represent zero correctly Initial Comment: Under python 2.3b2, the oct() function does not return '00' for 0 as the grammar specifies, but simply '0'. I believe this to be a bug because the hex() function returns '0x0' for zero. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766891&group_id=5470 From noreply@sourceforge.net Mon Jul 7 02:29:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 18:29:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 07:32 Message generated for change (Comment added) made by grittkmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kurt Grittner (grittkmg) Assigned to: Nobody/Anonymous (nobody) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 20:29 Message: Logged In: YES user_id=816888 I have a working fix for this problem, but the code is a fairly ugly hack. (A terrible thing to do to such a well organized codebase). 1. I exported a fini_socket() function from the PYD DLL. 2. I cloned the dynamic lookup function to check for the optional fini_socket() name as well as the init_socket(). If found, I remember it in a global. 3. In PyImport_Cleanup() I call the fini_socket() routine (if present) before these modules start getting freed. 4. In NTInit() I add to a counter instead of using atexit() 5. fini_socket() calls NTcleanup(), which simply calls WSACleanup 'counter' times to release the winsock DLL. This works, so now I can go on with my Python study. If anyone wants my hack code, just email me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 15:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 13:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 11:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Mon Jul 7 03:29:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 19:29:19 -0700 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 12:39 Message generated for change (Comment added) made by joshhoyt 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: Josh Hoyt (joshhoyt) Date: 2003-07-06 19: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 02: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@sourceforge.net Mon Jul 7 04:13:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 20:13:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 08:32 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kurt Grittner (grittkmg) Assigned to: Nobody/Anonymous (nobody) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-06 23:13 Message: Logged In: YES user_id=31435 Kurt, which versions of Windows and winsock.dll are you using? I continue to be unable to reproduce any problem here, and there have been no other reports of this despite thousands of Python programs using sockets on Windows for a decade. I have to conclude there's something unique in your setup. FYI, sometimes virus scanners and/or "personal firewalls" cause bizarre crashes during startup or shutdown. Are you running one (or more) of those? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 21:29 Message: Logged In: YES user_id=816888 I have a working fix for this problem, but the code is a fairly ugly hack. (A terrible thing to do to such a well organized codebase). 1. I exported a fini_socket() function from the PYD DLL. 2. I cloned the dynamic lookup function to check for the optional fini_socket() name as well as the init_socket(). If found, I remember it in a global. 3. In PyImport_Cleanup() I call the fini_socket() routine (if present) before these modules start getting freed. 4. In NTInit() I add to a counter instead of using atexit() 5. fini_socket() calls NTcleanup(), which simply calls WSACleanup 'counter' times to release the winsock DLL. This works, so now I can go on with my Python study. If anyone wants my hack code, just email me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 16:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 14:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 12:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Mon Jul 7 05:00:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 21:00:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 07:32 Message generated for change (Comment added) made by grittkmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kurt Grittner (grittkmg) Assigned to: Nobody/Anonymous (nobody) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 23:00 Message: Logged In: YES user_id=816888 Umm, this is not rocket science. WSACleanup() is being called in the wrong context. Startup is called in a DLL context. That puts the info in Thread Local Storage (TLS). The DLL Is allowed to unload with an atexit() pointer still pending to it. This is bad design. You should always call startup/cleanup in pairs and in the same thread context. As I said before this happens on every win98SE machine that I have tried it on. I have no firewall or virus scanner. This is a fairly recent installation of win98 with all of the MS updates for I.E. Apart from that, the most unusual thing is the presence of the VisualStudio 6.0 suite of programs. I can do a new install of win98SE on an old machine, just out of curiosity, but you only have to read this web site to see that this design for startup/cleanup calls is a recipie for disaster: http://support.microsoft.com/default.aspx?scid=http: //support.microsoft.com:80/support/kb/articles/Q237/5/72. ASP&NoWebContent=1 Here is a list of some of the modules running on my machine: USER32.DLL 4.10.2227 Microsoft Corporation Win32 USER32 core component C:\WINDOWS\SYSTEM\USER32. DLL 4/21/00 3:33:18 PM GMT Microsoft(R) Windows(R) Operating System bfc00000 - bfc11000 GDI32.DLL 4.10.1998 Microsoft Corporation Win32 GDI core component C:\WINDOWS\SYSTEM\GDI32. DLL 4/23/98 4:24:18 AM GMT Microsoft(R) Windows(R) Operating System bff20000 - bff46000 ADVAPI32.DLL 4.80.1675 Microsoft Corporation Win32 ADVAPI32 core component C: \WINDOWS\SYSTEM\ADVAPI32.DLL 4/23/99 4:37:33 PM GMT Microsoft(R) Windows(R) Operating System bfe80000 - bfe90000 KERNEL32.DLL 4.10.2222 Microsoft Corporation Win32 Kernel core component C: \WINDOWS\SYSTEM\KERNEL32.DLL 4/23/99 12:45:39 AM GMT Microsoft(R) Windows(R) Operating System bff70000 - bffe3000 MPR.DLL 4.10.1998 Microsoft Corporation WIN32 Network Interface DLL C:\WINDOWS\SYSTEM\MPR. DLL 4/23/99 4:37:36 PM GMT Microsoft(R) Windows(R) Operating System 7fbf0000 - 7fbfe000 MSNP32.DLL 4.10.2222 Microsoft Corporation Network provider for Microsoft networks C:\WINDOWS\SYSTEM\MSNP32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fb20000 - 7fb34000 MSNET32.DLL 4.10.2224 Microsoft Corporation Microsoft 32-bit Network API Library C: \WINDOWS\SYSTEM\MSNET32.DLL 11/12/99 4:15:15 AM GMT Microsoft(R) Windows(R) Operating System 7f300000 - 7f313000 MPREXE.EXE 4.10.1998 Microsoft Corporation WIN32 Network Interface Service Process C:\WINDOWS\SYSTEM\MPREXE.EXE 4/23/98 2:19:38 AM GMT Microsoft(R) Windows(R) Operating System 00500000 - 00507000 MPRSERV.DLL 4.10.2222 Microsoft Corporation Multinet Router C: \WINDOWS\SYSTEM\MPRSERV.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fad0000 - 7faf6000 NETAPI32.DLL 4.10.1998 Microsoft Corporation 32-bit network API DLL C: \WINDOWS\SYSTEM\NETAPI32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7f990000 - 7f995000 NETBIOS.DLL C:\WINDOWS\SYSTEM\NETBIOS. DLL 4/23/99 4:37:39 PM GMT 7f840000 - 7f848000 RNR20.DLL 4.10.2222 Microsoft Corporation Windows Socket2 NameSpace DLL C: \WINDOWS\SYSTEM\RNR20.DLL 4/23/99 4:38:44 PM GMT Microsoft(R) Windows(R) Operating System 783c0000 - 783cf000 MSAFD.DLL 4.10.1998 Microsoft Corporation Microsoft Windows Sockets 2.0 Service Provider C:\WINDOWS\SYSTEM\MSAFD.DLL 4/23/99 4: 38:11 PM GMT Microsoft(R) Windows(R) Operating System 7b410000 - 7b41b000 RPCLTSCM.DLL 4.71.2900 Microsoft Corporation Remote Process Control LTSCM DLL C: \WINDOWS\SYSTEM\RPCLTSCM.DLL 4/23/99 4:38:45 PM GMT Microsoft® Windows® Operating System 78320000 - 7832a000 WSOCK32.DLL 4.10.1998 Microsoft Corporation BSD Socket API for Windows C: \WINDOWS\SYSTEM\WSOCK32.DLL 4/23/99 4:39:14 PM GMT Microsoft(R) Windows(R) Operating System 75fa0000 - 75faa000 MSWSOCK.DLL 4.10.2222 Microsoft Corporation Microsoft WinSock Extension APIs C: \WINDOWS\SYSTEM\MSWSOCK.DLL 4/23/99 4:38:30 PM GMT Microsoft(R) Windows(R) Operating System 794d0000 - 794e5000 WS2_32.DLL 4.10.2222 Microsoft Corporation Windows Socket 2.0 32-Bit DLL C: \WINDOWS\SYSTEM\WS2_32.DLL 4/23/99 4:39:13 PM GMT Microsoft(R) Windows(R) Operating System 76000000 - 76012000 WS2HELP.DLL 4.10.1998 Microsoft Corporation Windows Socket 2.0 Helper for Windows 98 C:\WINDOWS\SYSTEM\WS2HELP.DLL 4/23/99 4: 39:13 PM GMT Microsoft(R) Windows(R) Operating System 75fe0000 - 75fe6000 DIGEST.DLL 6.00.2800.1106 Microsoft Corporation Digest SSPI Authentication Package C: \WINDOWS\SYSTEM\DIGEST.DLL 8/29/02 11:21:08 AM GMT Microsoft® Windows® Operating System 007a0000 - 007b0000 MSNSSPC.DLL 6.00.7753 Microsoft Corporation MSN Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSNSSPC.DLL 4/23/99 4:38:21 PM GMT Microsoft® Internet Services 7a210000 - 7a22f000 MSAPSSPC.DLL 5.00.7729 Microsoft Corporation DPA Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSAPSSPC.DLL 4/23/99 4:38:11 PM GMT Microsoft® Internet Services 7b3f0000 - 7b401000 MSVCRT40.DLL 4.22.0000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT40.DLL 4/23/99 4:38:29 PM GMT Microsoft® Visual C++ 79660000 - 796b5000 SECUR32.DLL 4.10.2222 Microsoft Corporation Microsoft Win32 Security Services C: \WINDOWS\SYSTEM\SECUR32.DLL 4/23/99 4:37:39 PM GMT Microsoft(R) Windows(R) Operating System 7f870000 - 7f87a000 RPCSS.EXE 4.71.2900 Microsoft Corporation Distributed COM Services C: \WINDOWS\SYSTEM\RPCSS.EXE 9/1/98 6:18:39 PM GMT Microsoft(R) Windows NT(TM) Operating System 01000000 - 01005000 MSVCRT20.DLL 2.11.000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT20.DLL 4/23/99 4:37:36 PM GMT Microsoft® Visual C++ 7fc30000 - 7fc75000 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 22:13 Message: Logged In: YES user_id=31435 Kurt, which versions of Windows and winsock.dll are you using? I continue to be unable to reproduce any problem here, and there have been no other reports of this despite thousands of Python programs using sockets on Windows for a decade. I have to conclude there's something unique in your setup. FYI, sometimes virus scanners and/or "personal firewalls" cause bizarre crashes during startup or shutdown. Are you running one (or more) of those? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 20:29 Message: Logged In: YES user_id=816888 I have a working fix for this problem, but the code is a fairly ugly hack. (A terrible thing to do to such a well organized codebase). 1. I exported a fini_socket() function from the PYD DLL. 2. I cloned the dynamic lookup function to check for the optional fini_socket() name as well as the init_socket(). If found, I remember it in a global. 3. In PyImport_Cleanup() I call the fini_socket() routine (if present) before these modules start getting freed. 4. In NTInit() I add to a counter instead of using atexit() 5. fini_socket() calls NTcleanup(), which simply calls WSACleanup 'counter' times to release the winsock DLL. This works, so now I can go on with my Python study. If anyone wants my hack code, just email me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 15:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 13:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 11:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Mon Jul 7 05:21:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 21:21:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 08:32 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kurt Grittner (grittkmg) Assigned to: Nobody/Anonymous (nobody) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-07 00:21 Message: Logged In: YES user_id=31435 You're trying too hard . I'm not arguing about the design (for one thing, it's not my design, and I don't know anything about it), I'm wondering both why I can't reproduce a problem, and especially why no other report of this has ever been made. You surely don't believe you're the only programmer to try sockets in Python on Windows, right? I also tried it under an up-to-date Win98SE, also with MSVC 6 and all current IE 6 patches. Indeed, that's the machine I've built the PythonLabs Windows installer *on* for the last two years. No problem. Everyone who has ever run the Python test suite on Windows has exercised sockets on Windows, and so has anyone who has ever run Zope on Windows, etc. It may indeed be a bit of Rocket Science if you don't have a theory for why it fails only when you run it! The reason I'm keen to know is that only someone who can see the problem can test a putative fix (and so confirm-- or refute --that the problem goes away). ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 00:00 Message: Logged In: YES user_id=816888 Umm, this is not rocket science. WSACleanup() is being called in the wrong context. Startup is called in a DLL context. That puts the info in Thread Local Storage (TLS). The DLL Is allowed to unload with an atexit() pointer still pending to it. This is bad design. You should always call startup/cleanup in pairs and in the same thread context. As I said before this happens on every win98SE machine that I have tried it on. I have no firewall or virus scanner. This is a fairly recent installation of win98 with all of the MS updates for I.E. Apart from that, the most unusual thing is the presence of the VisualStudio 6.0 suite of programs. I can do a new install of win98SE on an old machine, just out of curiosity, but you only have to read this web site to see that this design for startup/cleanup calls is a recipie for disaster: http://support.microsoft.com/default.aspx?scid=http: //support.microsoft.com:80/support/kb/articles/Q237/5/72. ASP&NoWebContent=1 Here is a list of some of the modules running on my machine: USER32.DLL 4.10.2227 Microsoft Corporation Win32 USER32 core component C:\WINDOWS\SYSTEM\USER32. DLL 4/21/00 3:33:18 PM GMT Microsoft(R) Windows(R) Operating System bfc00000 - bfc11000 GDI32.DLL 4.10.1998 Microsoft Corporation Win32 GDI core component C:\WINDOWS\SYSTEM\GDI32. DLL 4/23/98 4:24:18 AM GMT Microsoft(R) Windows(R) Operating System bff20000 - bff46000 ADVAPI32.DLL 4.80.1675 Microsoft Corporation Win32 ADVAPI32 core component C: \WINDOWS\SYSTEM\ADVAPI32.DLL 4/23/99 4:37:33 PM GMT Microsoft(R) Windows(R) Operating System bfe80000 - bfe90000 KERNEL32.DLL 4.10.2222 Microsoft Corporation Win32 Kernel core component C: \WINDOWS\SYSTEM\KERNEL32.DLL 4/23/99 12:45:39 AM GMT Microsoft(R) Windows(R) Operating System bff70000 - bffe3000 MPR.DLL 4.10.1998 Microsoft Corporation WIN32 Network Interface DLL C:\WINDOWS\SYSTEM\MPR. DLL 4/23/99 4:37:36 PM GMT Microsoft(R) Windows(R) Operating System 7fbf0000 - 7fbfe000 MSNP32.DLL 4.10.2222 Microsoft Corporation Network provider for Microsoft networks C:\WINDOWS\SYSTEM\MSNP32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fb20000 - 7fb34000 MSNET32.DLL 4.10.2224 Microsoft Corporation Microsoft 32-bit Network API Library C: \WINDOWS\SYSTEM\MSNET32.DLL 11/12/99 4:15:15 AM GMT Microsoft(R) Windows(R) Operating System 7f300000 - 7f313000 MPREXE.EXE 4.10.1998 Microsoft Corporation WIN32 Network Interface Service Process C:\WINDOWS\SYSTEM\MPREXE.EXE 4/23/98 2:19:38 AM GMT Microsoft(R) Windows(R) Operating System 00500000 - 00507000 MPRSERV.DLL 4.10.2222 Microsoft Corporation Multinet Router C: \WINDOWS\SYSTEM\MPRSERV.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fad0000 - 7faf6000 NETAPI32.DLL 4.10.1998 Microsoft Corporation 32-bit network API DLL C: \WINDOWS\SYSTEM\NETAPI32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7f990000 - 7f995000 NETBIOS.DLL C:\WINDOWS\SYSTEM\NETBIOS. DLL 4/23/99 4:37:39 PM GMT 7f840000 - 7f848000 RNR20.DLL 4.10.2222 Microsoft Corporation Windows Socket2 NameSpace DLL C: \WINDOWS\SYSTEM\RNR20.DLL 4/23/99 4:38:44 PM GMT Microsoft(R) Windows(R) Operating System 783c0000 - 783cf000 MSAFD.DLL 4.10.1998 Microsoft Corporation Microsoft Windows Sockets 2.0 Service Provider C:\WINDOWS\SYSTEM\MSAFD.DLL 4/23/99 4: 38:11 PM GMT Microsoft(R) Windows(R) Operating System 7b410000 - 7b41b000 RPCLTSCM.DLL 4.71.2900 Microsoft Corporation Remote Process Control LTSCM DLL C: \WINDOWS\SYSTEM\RPCLTSCM.DLL 4/23/99 4:38:45 PM GMT Microsoft® Windows® Operating System 78320000 - 7832a000 WSOCK32.DLL 4.10.1998 Microsoft Corporation BSD Socket API for Windows C: \WINDOWS\SYSTEM\WSOCK32.DLL 4/23/99 4:39:14 PM GMT Microsoft(R) Windows(R) Operating System 75fa0000 - 75faa000 MSWSOCK.DLL 4.10.2222 Microsoft Corporation Microsoft WinSock Extension APIs C: \WINDOWS\SYSTEM\MSWSOCK.DLL 4/23/99 4:38:30 PM GMT Microsoft(R) Windows(R) Operating System 794d0000 - 794e5000 WS2_32.DLL 4.10.2222 Microsoft Corporation Windows Socket 2.0 32-Bit DLL C: \WINDOWS\SYSTEM\WS2_32.DLL 4/23/99 4:39:13 PM GMT Microsoft(R) Windows(R) Operating System 76000000 - 76012000 WS2HELP.DLL 4.10.1998 Microsoft Corporation Windows Socket 2.0 Helper for Windows 98 C:\WINDOWS\SYSTEM\WS2HELP.DLL 4/23/99 4: 39:13 PM GMT Microsoft(R) Windows(R) Operating System 75fe0000 - 75fe6000 DIGEST.DLL 6.00.2800.1106 Microsoft Corporation Digest SSPI Authentication Package C: \WINDOWS\SYSTEM\DIGEST.DLL 8/29/02 11:21:08 AM GMT Microsoft® Windows® Operating System 007a0000 - 007b0000 MSNSSPC.DLL 6.00.7753 Microsoft Corporation MSN Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSNSSPC.DLL 4/23/99 4:38:21 PM GMT Microsoft® Internet Services 7a210000 - 7a22f000 MSAPSSPC.DLL 5.00.7729 Microsoft Corporation DPA Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSAPSSPC.DLL 4/23/99 4:38:11 PM GMT Microsoft® Internet Services 7b3f0000 - 7b401000 MSVCRT40.DLL 4.22.0000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT40.DLL 4/23/99 4:38:29 PM GMT Microsoft® Visual C++ 79660000 - 796b5000 SECUR32.DLL 4.10.2222 Microsoft Corporation Microsoft Win32 Security Services C: \WINDOWS\SYSTEM\SECUR32.DLL 4/23/99 4:37:39 PM GMT Microsoft(R) Windows(R) Operating System 7f870000 - 7f87a000 RPCSS.EXE 4.71.2900 Microsoft Corporation Distributed COM Services C: \WINDOWS\SYSTEM\RPCSS.EXE 9/1/98 6:18:39 PM GMT Microsoft(R) Windows NT(TM) Operating System 01000000 - 01005000 MSVCRT20.DLL 2.11.000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT20.DLL 4/23/99 4:37:36 PM GMT Microsoft® Visual C++ 7fc30000 - 7fc75000 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 23:13 Message: Logged In: YES user_id=31435 Kurt, which versions of Windows and winsock.dll are you using? I continue to be unable to reproduce any problem here, and there have been no other reports of this despite thousands of Python programs using sockets on Windows for a decade. I have to conclude there's something unique in your setup. FYI, sometimes virus scanners and/or "personal firewalls" cause bizarre crashes during startup or shutdown. Are you running one (or more) of those? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 21:29 Message: Logged In: YES user_id=816888 I have a working fix for this problem, but the code is a fairly ugly hack. (A terrible thing to do to such a well organized codebase). 1. I exported a fini_socket() function from the PYD DLL. 2. I cloned the dynamic lookup function to check for the optional fini_socket() name as well as the init_socket(). If found, I remember it in a global. 3. In PyImport_Cleanup() I call the fini_socket() routine (if present) before these modules start getting freed. 4. In NTInit() I add to a counter instead of using atexit() 5. fini_socket() calls NTcleanup(), which simply calls WSACleanup 'counter' times to release the winsock DLL. This works, so now I can go on with my Python study. If anyone wants my hack code, just email me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 16:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 14:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 12:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Mon Jul 7 05:26:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 21:26:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 08:32 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Kurt Grittner (grittkmg) >Assigned to: Mark Hammond (mhammond) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-07 00:26 Message: Logged In: YES user_id=31435 Mark, can you take a look at this? If you agree the design is hosed, it would be good to fix it before 2.3r1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-07 00:21 Message: Logged In: YES user_id=31435 You're trying too hard . I'm not arguing about the design (for one thing, it's not my design, and I don't know anything about it), I'm wondering both why I can't reproduce a problem, and especially why no other report of this has ever been made. You surely don't believe you're the only programmer to try sockets in Python on Windows, right? I also tried it under an up-to-date Win98SE, also with MSVC 6 and all current IE 6 patches. Indeed, that's the machine I've built the PythonLabs Windows installer *on* for the last two years. No problem. Everyone who has ever run the Python test suite on Windows has exercised sockets on Windows, and so has anyone who has ever run Zope on Windows, etc. It may indeed be a bit of Rocket Science if you don't have a theory for why it fails only when you run it! The reason I'm keen to know is that only someone who can see the problem can test a putative fix (and so confirm-- or refute --that the problem goes away). ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 00:00 Message: Logged In: YES user_id=816888 Umm, this is not rocket science. WSACleanup() is being called in the wrong context. Startup is called in a DLL context. That puts the info in Thread Local Storage (TLS). The DLL Is allowed to unload with an atexit() pointer still pending to it. This is bad design. You should always call startup/cleanup in pairs and in the same thread context. As I said before this happens on every win98SE machine that I have tried it on. I have no firewall or virus scanner. This is a fairly recent installation of win98 with all of the MS updates for I.E. Apart from that, the most unusual thing is the presence of the VisualStudio 6.0 suite of programs. I can do a new install of win98SE on an old machine, just out of curiosity, but you only have to read this web site to see that this design for startup/cleanup calls is a recipie for disaster: http://support.microsoft.com/default.aspx?scid=http: //support.microsoft.com:80/support/kb/articles/Q237/5/72. ASP&NoWebContent=1 Here is a list of some of the modules running on my machine: USER32.DLL 4.10.2227 Microsoft Corporation Win32 USER32 core component C:\WINDOWS\SYSTEM\USER32. DLL 4/21/00 3:33:18 PM GMT Microsoft(R) Windows(R) Operating System bfc00000 - bfc11000 GDI32.DLL 4.10.1998 Microsoft Corporation Win32 GDI core component C:\WINDOWS\SYSTEM\GDI32. DLL 4/23/98 4:24:18 AM GMT Microsoft(R) Windows(R) Operating System bff20000 - bff46000 ADVAPI32.DLL 4.80.1675 Microsoft Corporation Win32 ADVAPI32 core component C: \WINDOWS\SYSTEM\ADVAPI32.DLL 4/23/99 4:37:33 PM GMT Microsoft(R) Windows(R) Operating System bfe80000 - bfe90000 KERNEL32.DLL 4.10.2222 Microsoft Corporation Win32 Kernel core component C: \WINDOWS\SYSTEM\KERNEL32.DLL 4/23/99 12:45:39 AM GMT Microsoft(R) Windows(R) Operating System bff70000 - bffe3000 MPR.DLL 4.10.1998 Microsoft Corporation WIN32 Network Interface DLL C:\WINDOWS\SYSTEM\MPR. DLL 4/23/99 4:37:36 PM GMT Microsoft(R) Windows(R) Operating System 7fbf0000 - 7fbfe000 MSNP32.DLL 4.10.2222 Microsoft Corporation Network provider for Microsoft networks C:\WINDOWS\SYSTEM\MSNP32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fb20000 - 7fb34000 MSNET32.DLL 4.10.2224 Microsoft Corporation Microsoft 32-bit Network API Library C: \WINDOWS\SYSTEM\MSNET32.DLL 11/12/99 4:15:15 AM GMT Microsoft(R) Windows(R) Operating System 7f300000 - 7f313000 MPREXE.EXE 4.10.1998 Microsoft Corporation WIN32 Network Interface Service Process C:\WINDOWS\SYSTEM\MPREXE.EXE 4/23/98 2:19:38 AM GMT Microsoft(R) Windows(R) Operating System 00500000 - 00507000 MPRSERV.DLL 4.10.2222 Microsoft Corporation Multinet Router C: \WINDOWS\SYSTEM\MPRSERV.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fad0000 - 7faf6000 NETAPI32.DLL 4.10.1998 Microsoft Corporation 32-bit network API DLL C: \WINDOWS\SYSTEM\NETAPI32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7f990000 - 7f995000 NETBIOS.DLL C:\WINDOWS\SYSTEM\NETBIOS. DLL 4/23/99 4:37:39 PM GMT 7f840000 - 7f848000 RNR20.DLL 4.10.2222 Microsoft Corporation Windows Socket2 NameSpace DLL C: \WINDOWS\SYSTEM\RNR20.DLL 4/23/99 4:38:44 PM GMT Microsoft(R) Windows(R) Operating System 783c0000 - 783cf000 MSAFD.DLL 4.10.1998 Microsoft Corporation Microsoft Windows Sockets 2.0 Service Provider C:\WINDOWS\SYSTEM\MSAFD.DLL 4/23/99 4: 38:11 PM GMT Microsoft(R) Windows(R) Operating System 7b410000 - 7b41b000 RPCLTSCM.DLL 4.71.2900 Microsoft Corporation Remote Process Control LTSCM DLL C: \WINDOWS\SYSTEM\RPCLTSCM.DLL 4/23/99 4:38:45 PM GMT Microsoft® Windows® Operating System 78320000 - 7832a000 WSOCK32.DLL 4.10.1998 Microsoft Corporation BSD Socket API for Windows C: \WINDOWS\SYSTEM\WSOCK32.DLL 4/23/99 4:39:14 PM GMT Microsoft(R) Windows(R) Operating System 75fa0000 - 75faa000 MSWSOCK.DLL 4.10.2222 Microsoft Corporation Microsoft WinSock Extension APIs C: \WINDOWS\SYSTEM\MSWSOCK.DLL 4/23/99 4:38:30 PM GMT Microsoft(R) Windows(R) Operating System 794d0000 - 794e5000 WS2_32.DLL 4.10.2222 Microsoft Corporation Windows Socket 2.0 32-Bit DLL C: \WINDOWS\SYSTEM\WS2_32.DLL 4/23/99 4:39:13 PM GMT Microsoft(R) Windows(R) Operating System 76000000 - 76012000 WS2HELP.DLL 4.10.1998 Microsoft Corporation Windows Socket 2.0 Helper for Windows 98 C:\WINDOWS\SYSTEM\WS2HELP.DLL 4/23/99 4: 39:13 PM GMT Microsoft(R) Windows(R) Operating System 75fe0000 - 75fe6000 DIGEST.DLL 6.00.2800.1106 Microsoft Corporation Digest SSPI Authentication Package C: \WINDOWS\SYSTEM\DIGEST.DLL 8/29/02 11:21:08 AM GMT Microsoft® Windows® Operating System 007a0000 - 007b0000 MSNSSPC.DLL 6.00.7753 Microsoft Corporation MSN Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSNSSPC.DLL 4/23/99 4:38:21 PM GMT Microsoft® Internet Services 7a210000 - 7a22f000 MSAPSSPC.DLL 5.00.7729 Microsoft Corporation DPA Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSAPSSPC.DLL 4/23/99 4:38:11 PM GMT Microsoft® Internet Services 7b3f0000 - 7b401000 MSVCRT40.DLL 4.22.0000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT40.DLL 4/23/99 4:38:29 PM GMT Microsoft® Visual C++ 79660000 - 796b5000 SECUR32.DLL 4.10.2222 Microsoft Corporation Microsoft Win32 Security Services C: \WINDOWS\SYSTEM\SECUR32.DLL 4/23/99 4:37:39 PM GMT Microsoft(R) Windows(R) Operating System 7f870000 - 7f87a000 RPCSS.EXE 4.71.2900 Microsoft Corporation Distributed COM Services C: \WINDOWS\SYSTEM\RPCSS.EXE 9/1/98 6:18:39 PM GMT Microsoft(R) Windows NT(TM) Operating System 01000000 - 01005000 MSVCRT20.DLL 2.11.000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT20.DLL 4/23/99 4:37:36 PM GMT Microsoft® Visual C++ 7fc30000 - 7fc75000 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 23:13 Message: Logged In: YES user_id=31435 Kurt, which versions of Windows and winsock.dll are you using? I continue to be unable to reproduce any problem here, and there have been no other reports of this despite thousands of Python programs using sockets on Windows for a decade. I have to conclude there's something unique in your setup. FYI, sometimes virus scanners and/or "personal firewalls" cause bizarre crashes during startup or shutdown. Are you running one (or more) of those? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 21:29 Message: Logged In: YES user_id=816888 I have a working fix for this problem, but the code is a fairly ugly hack. (A terrible thing to do to such a well organized codebase). 1. I exported a fini_socket() function from the PYD DLL. 2. I cloned the dynamic lookup function to check for the optional fini_socket() name as well as the init_socket(). If found, I remember it in a global. 3. In PyImport_Cleanup() I call the fini_socket() routine (if present) before these modules start getting freed. 4. In NTInit() I add to a counter instead of using atexit() 5. fini_socket() calls NTcleanup(), which simply calls WSACleanup 'counter' times to release the winsock DLL. This works, so now I can go on with my Python study. If anyone wants my hack code, just email me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 16:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 14:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 12:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Mon Jul 7 06:00:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 22:00:52 -0700 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-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@sourceforge.net Mon Jul 7 06:03:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 22:03:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-766696 ] gcc-3.3: dereferencing type-punned pointer Message-ID: Bugs item #766696, was opened at 2003-07-06 16:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766696&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: gcc-3.3: dereferencing type-punned pointer Initial Comment: Building with gcc-3.3 leads to about 250 warnings 263 dereferencing type-punned pointer will break strict-aliasing rules Include/intobject.h:#define Py_True ((PyObject *) &_Py_TrueStruct) although the test results look good. Please add -fno-strict-aliasing to the compiler flags, when compiling with gcc-3.3 or up. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 07:03 Message: Logged In: YES user_id=21627 Can you provide a patch for that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766696&group_id=5470 From noreply@sourceforge.net Mon Jul 7 07:13:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 06 Jul 2003 23:13:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 07:32 Message generated for change (Comment added) made by grittkmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 7 Submitted By: Kurt Grittner (grittkmg) Assigned to: Mark Hammond (mhammond) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 01:13 Message: Logged In: YES user_id=816888 Well, Python is new to me, but Win32 isn't. My theory for why it fails is simply that the program breaks the rules and creates a window for failure. On my system the window is large. On yours, the window is smaller. This is a machine with lots of memory. (AMD XP2000, 512MB RAM). It has a new hard drive with an on board 8MB cache. Things happen fast on this machine. This single fact could explain why the failure condition always wins the race for me. The machines at work (which also fail) are similar. Who puts win98SE on a brand new machine these days? Hmmm... maybe not too many people. I can turn your argument around... I have dozens of network programs running on this machine, many of which I wrote, none of which play fast-and-loose with threaded-DLL's, all of which work. Python is the only network program that fails. It fails every single time. I luckily have access to the source, so I can find the bug and fix it. Great! The wonders of open source. Well, anyhow, I was only trying to lend a hand. Python looks promising. I am looking at it as a potential replacement for VB/ActiveX. I am going to try this on some older, slower machines. Also, I will attempt to code a demo program that reproduces the bad behavior by duplicating the steps taken in the socketmodule, and hopefully also duplicating the error on more machines. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 23:26 Message: Logged In: YES user_id=31435 Mark, can you take a look at this? If you agree the design is hosed, it would be good to fix it before 2.3r1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 23:21 Message: Logged In: YES user_id=31435 You're trying too hard . I'm not arguing about the design (for one thing, it's not my design, and I don't know anything about it), I'm wondering both why I can't reproduce a problem, and especially why no other report of this has ever been made. You surely don't believe you're the only programmer to try sockets in Python on Windows, right? I also tried it under an up-to-date Win98SE, also with MSVC 6 and all current IE 6 patches. Indeed, that's the machine I've built the PythonLabs Windows installer *on* for the last two years. No problem. Everyone who has ever run the Python test suite on Windows has exercised sockets on Windows, and so has anyone who has ever run Zope on Windows, etc. It may indeed be a bit of Rocket Science if you don't have a theory for why it fails only when you run it! The reason I'm keen to know is that only someone who can see the problem can test a putative fix (and so confirm-- or refute --that the problem goes away). ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 23:00 Message: Logged In: YES user_id=816888 Umm, this is not rocket science. WSACleanup() is being called in the wrong context. Startup is called in a DLL context. That puts the info in Thread Local Storage (TLS). The DLL Is allowed to unload with an atexit() pointer still pending to it. This is bad design. You should always call startup/cleanup in pairs and in the same thread context. As I said before this happens on every win98SE machine that I have tried it on. I have no firewall or virus scanner. This is a fairly recent installation of win98 with all of the MS updates for I.E. Apart from that, the most unusual thing is the presence of the VisualStudio 6.0 suite of programs. I can do a new install of win98SE on an old machine, just out of curiosity, but you only have to read this web site to see that this design for startup/cleanup calls is a recipie for disaster: http://support.microsoft.com/default.aspx?scid=http: //support.microsoft.com:80/support/kb/articles/Q237/5/72. ASP&NoWebContent=1 Here is a list of some of the modules running on my machine: USER32.DLL 4.10.2227 Microsoft Corporation Win32 USER32 core component C:\WINDOWS\SYSTEM\USER32. DLL 4/21/00 3:33:18 PM GMT Microsoft(R) Windows(R) Operating System bfc00000 - bfc11000 GDI32.DLL 4.10.1998 Microsoft Corporation Win32 GDI core component C:\WINDOWS\SYSTEM\GDI32. DLL 4/23/98 4:24:18 AM GMT Microsoft(R) Windows(R) Operating System bff20000 - bff46000 ADVAPI32.DLL 4.80.1675 Microsoft Corporation Win32 ADVAPI32 core component C: \WINDOWS\SYSTEM\ADVAPI32.DLL 4/23/99 4:37:33 PM GMT Microsoft(R) Windows(R) Operating System bfe80000 - bfe90000 KERNEL32.DLL 4.10.2222 Microsoft Corporation Win32 Kernel core component C: \WINDOWS\SYSTEM\KERNEL32.DLL 4/23/99 12:45:39 AM GMT Microsoft(R) Windows(R) Operating System bff70000 - bffe3000 MPR.DLL 4.10.1998 Microsoft Corporation WIN32 Network Interface DLL C:\WINDOWS\SYSTEM\MPR. DLL 4/23/99 4:37:36 PM GMT Microsoft(R) Windows(R) Operating System 7fbf0000 - 7fbfe000 MSNP32.DLL 4.10.2222 Microsoft Corporation Network provider for Microsoft networks C:\WINDOWS\SYSTEM\MSNP32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fb20000 - 7fb34000 MSNET32.DLL 4.10.2224 Microsoft Corporation Microsoft 32-bit Network API Library C: \WINDOWS\SYSTEM\MSNET32.DLL 11/12/99 4:15:15 AM GMT Microsoft(R) Windows(R) Operating System 7f300000 - 7f313000 MPREXE.EXE 4.10.1998 Microsoft Corporation WIN32 Network Interface Service Process C:\WINDOWS\SYSTEM\MPREXE.EXE 4/23/98 2:19:38 AM GMT Microsoft(R) Windows(R) Operating System 00500000 - 00507000 MPRSERV.DLL 4.10.2222 Microsoft Corporation Multinet Router C: \WINDOWS\SYSTEM\MPRSERV.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fad0000 - 7faf6000 NETAPI32.DLL 4.10.1998 Microsoft Corporation 32-bit network API DLL C: \WINDOWS\SYSTEM\NETAPI32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7f990000 - 7f995000 NETBIOS.DLL C:\WINDOWS\SYSTEM\NETBIOS. DLL 4/23/99 4:37:39 PM GMT 7f840000 - 7f848000 RNR20.DLL 4.10.2222 Microsoft Corporation Windows Socket2 NameSpace DLL C: \WINDOWS\SYSTEM\RNR20.DLL 4/23/99 4:38:44 PM GMT Microsoft(R) Windows(R) Operating System 783c0000 - 783cf000 MSAFD.DLL 4.10.1998 Microsoft Corporation Microsoft Windows Sockets 2.0 Service Provider C:\WINDOWS\SYSTEM\MSAFD.DLL 4/23/99 4: 38:11 PM GMT Microsoft(R) Windows(R) Operating System 7b410000 - 7b41b000 RPCLTSCM.DLL 4.71.2900 Microsoft Corporation Remote Process Control LTSCM DLL C: \WINDOWS\SYSTEM\RPCLTSCM.DLL 4/23/99 4:38:45 PM GMT Microsoft® Windows® Operating System 78320000 - 7832a000 WSOCK32.DLL 4.10.1998 Microsoft Corporation BSD Socket API for Windows C: \WINDOWS\SYSTEM\WSOCK32.DLL 4/23/99 4:39:14 PM GMT Microsoft(R) Windows(R) Operating System 75fa0000 - 75faa000 MSWSOCK.DLL 4.10.2222 Microsoft Corporation Microsoft WinSock Extension APIs C: \WINDOWS\SYSTEM\MSWSOCK.DLL 4/23/99 4:38:30 PM GMT Microsoft(R) Windows(R) Operating System 794d0000 - 794e5000 WS2_32.DLL 4.10.2222 Microsoft Corporation Windows Socket 2.0 32-Bit DLL C: \WINDOWS\SYSTEM\WS2_32.DLL 4/23/99 4:39:13 PM GMT Microsoft(R) Windows(R) Operating System 76000000 - 76012000 WS2HELP.DLL 4.10.1998 Microsoft Corporation Windows Socket 2.0 Helper for Windows 98 C:\WINDOWS\SYSTEM\WS2HELP.DLL 4/23/99 4: 39:13 PM GMT Microsoft(R) Windows(R) Operating System 75fe0000 - 75fe6000 DIGEST.DLL 6.00.2800.1106 Microsoft Corporation Digest SSPI Authentication Package C: \WINDOWS\SYSTEM\DIGEST.DLL 8/29/02 11:21:08 AM GMT Microsoft® Windows® Operating System 007a0000 - 007b0000 MSNSSPC.DLL 6.00.7753 Microsoft Corporation MSN Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSNSSPC.DLL 4/23/99 4:38:21 PM GMT Microsoft® Internet Services 7a210000 - 7a22f000 MSAPSSPC.DLL 5.00.7729 Microsoft Corporation DPA Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSAPSSPC.DLL 4/23/99 4:38:11 PM GMT Microsoft® Internet Services 7b3f0000 - 7b401000 MSVCRT40.DLL 4.22.0000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT40.DLL 4/23/99 4:38:29 PM GMT Microsoft® Visual C++ 79660000 - 796b5000 SECUR32.DLL 4.10.2222 Microsoft Corporation Microsoft Win32 Security Services C: \WINDOWS\SYSTEM\SECUR32.DLL 4/23/99 4:37:39 PM GMT Microsoft(R) Windows(R) Operating System 7f870000 - 7f87a000 RPCSS.EXE 4.71.2900 Microsoft Corporation Distributed COM Services C: \WINDOWS\SYSTEM\RPCSS.EXE 9/1/98 6:18:39 PM GMT Microsoft(R) Windows NT(TM) Operating System 01000000 - 01005000 MSVCRT20.DLL 2.11.000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT20.DLL 4/23/99 4:37:36 PM GMT Microsoft® Visual C++ 7fc30000 - 7fc75000 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 22:13 Message: Logged In: YES user_id=31435 Kurt, which versions of Windows and winsock.dll are you using? I continue to be unable to reproduce any problem here, and there have been no other reports of this despite thousands of Python programs using sockets on Windows for a decade. I have to conclude there's something unique in your setup. FYI, sometimes virus scanners and/or "personal firewalls" cause bizarre crashes during startup or shutdown. Are you running one (or more) of those? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 20:29 Message: Logged In: YES user_id=816888 I have a working fix for this problem, but the code is a fairly ugly hack. (A terrible thing to do to such a well organized codebase). 1. I exported a fini_socket() function from the PYD DLL. 2. I cloned the dynamic lookup function to check for the optional fini_socket() name as well as the init_socket(). If found, I remember it in a global. 3. In PyImport_Cleanup() I call the fini_socket() routine (if present) before these modules start getting freed. 4. In NTInit() I add to a counter instead of using atexit() 5. fini_socket() calls NTcleanup(), which simply calls WSACleanup 'counter' times to release the winsock DLL. This works, so now I can go on with my Python study. If anyone wants my hack code, just email me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 15:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 13:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 11:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Mon Jul 7 10:16:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 02:16:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-766696 ] gcc-3.3: dereferencing type-punned pointer Message-ID: Bugs item #766696, was opened at 2003-07-06 14:04 Message generated for change (Comment added) made by doko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766696&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: gcc-3.3: dereferencing type-punned pointer Initial Comment: Building with gcc-3.3 leads to about 250 warnings 263 dereferencing type-punned pointer will break strict-aliasing rules Include/intobject.h:#define Py_True ((PyObject *) &_Py_TrueStruct) although the test results look good. Please add -fno-strict-aliasing to the compiler flags, when compiling with gcc-3.3 or up. ---------------------------------------------------------------------- >Comment By: Matthias Klose (doko) Date: 2003-07-07 09:16 Message: Logged In: YES user_id=60903 attached. if correct, please apply to the branch as well. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 05:03 Message: Logged In: YES user_id=21627 Can you provide a patch for that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766696&group_id=5470 From noreply@sourceforge.net Mon Jul 7 10:34:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 02:34:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 07:32 Message generated for change (Comment added) made by grittkmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 7 Submitted By: Kurt Grittner (grittkmg) Assigned to: Mark Hammond (mhammond) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 04:34 Message: Logged In: YES user_id=816888 Here is a small windows project that causes the error for me on my faster machines. I will try it on a bunch of other machines. badsock good Runs it the good way badsock bad or just plain badsock Causes the error for me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 01:13 Message: Logged In: YES user_id=816888 Well, Python is new to me, but Win32 isn't. My theory for why it fails is simply that the program breaks the rules and creates a window for failure. On my system the window is large. On yours, the window is smaller. This is a machine with lots of memory. (AMD XP2000, 512MB RAM). It has a new hard drive with an on board 8MB cache. Things happen fast on this machine. This single fact could explain why the failure condition always wins the race for me. The machines at work (which also fail) are similar. Who puts win98SE on a brand new machine these days? Hmmm... maybe not too many people. I can turn your argument around... I have dozens of network programs running on this machine, many of which I wrote, none of which play fast-and-loose with threaded-DLL's, all of which work. Python is the only network program that fails. It fails every single time. I luckily have access to the source, so I can find the bug and fix it. Great! The wonders of open source. Well, anyhow, I was only trying to lend a hand. Python looks promising. I am looking at it as a potential replacement for VB/ActiveX. I am going to try this on some older, slower machines. Also, I will attempt to code a demo program that reproduces the bad behavior by duplicating the steps taken in the socketmodule, and hopefully also duplicating the error on more machines. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 23:26 Message: Logged In: YES user_id=31435 Mark, can you take a look at this? If you agree the design is hosed, it would be good to fix it before 2.3r1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 23:21 Message: Logged In: YES user_id=31435 You're trying too hard . I'm not arguing about the design (for one thing, it's not my design, and I don't know anything about it), I'm wondering both why I can't reproduce a problem, and especially why no other report of this has ever been made. You surely don't believe you're the only programmer to try sockets in Python on Windows, right? I also tried it under an up-to-date Win98SE, also with MSVC 6 and all current IE 6 patches. Indeed, that's the machine I've built the PythonLabs Windows installer *on* for the last two years. No problem. Everyone who has ever run the Python test suite on Windows has exercised sockets on Windows, and so has anyone who has ever run Zope on Windows, etc. It may indeed be a bit of Rocket Science if you don't have a theory for why it fails only when you run it! The reason I'm keen to know is that only someone who can see the problem can test a putative fix (and so confirm-- or refute --that the problem goes away). ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 23:00 Message: Logged In: YES user_id=816888 Umm, this is not rocket science. WSACleanup() is being called in the wrong context. Startup is called in a DLL context. That puts the info in Thread Local Storage (TLS). The DLL Is allowed to unload with an atexit() pointer still pending to it. This is bad design. You should always call startup/cleanup in pairs and in the same thread context. As I said before this happens on every win98SE machine that I have tried it on. I have no firewall or virus scanner. This is a fairly recent installation of win98 with all of the MS updates for I.E. Apart from that, the most unusual thing is the presence of the VisualStudio 6.0 suite of programs. I can do a new install of win98SE on an old machine, just out of curiosity, but you only have to read this web site to see that this design for startup/cleanup calls is a recipie for disaster: http://support.microsoft.com/default.aspx?scid=http: //support.microsoft.com:80/support/kb/articles/Q237/5/72. ASP&NoWebContent=1 Here is a list of some of the modules running on my machine: USER32.DLL 4.10.2227 Microsoft Corporation Win32 USER32 core component C:\WINDOWS\SYSTEM\USER32. DLL 4/21/00 3:33:18 PM GMT Microsoft(R) Windows(R) Operating System bfc00000 - bfc11000 GDI32.DLL 4.10.1998 Microsoft Corporation Win32 GDI core component C:\WINDOWS\SYSTEM\GDI32. DLL 4/23/98 4:24:18 AM GMT Microsoft(R) Windows(R) Operating System bff20000 - bff46000 ADVAPI32.DLL 4.80.1675 Microsoft Corporation Win32 ADVAPI32 core component C: \WINDOWS\SYSTEM\ADVAPI32.DLL 4/23/99 4:37:33 PM GMT Microsoft(R) Windows(R) Operating System bfe80000 - bfe90000 KERNEL32.DLL 4.10.2222 Microsoft Corporation Win32 Kernel core component C: \WINDOWS\SYSTEM\KERNEL32.DLL 4/23/99 12:45:39 AM GMT Microsoft(R) Windows(R) Operating System bff70000 - bffe3000 MPR.DLL 4.10.1998 Microsoft Corporation WIN32 Network Interface DLL C:\WINDOWS\SYSTEM\MPR. DLL 4/23/99 4:37:36 PM GMT Microsoft(R) Windows(R) Operating System 7fbf0000 - 7fbfe000 MSNP32.DLL 4.10.2222 Microsoft Corporation Network provider for Microsoft networks C:\WINDOWS\SYSTEM\MSNP32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fb20000 - 7fb34000 MSNET32.DLL 4.10.2224 Microsoft Corporation Microsoft 32-bit Network API Library C: \WINDOWS\SYSTEM\MSNET32.DLL 11/12/99 4:15:15 AM GMT Microsoft(R) Windows(R) Operating System 7f300000 - 7f313000 MPREXE.EXE 4.10.1998 Microsoft Corporation WIN32 Network Interface Service Process C:\WINDOWS\SYSTEM\MPREXE.EXE 4/23/98 2:19:38 AM GMT Microsoft(R) Windows(R) Operating System 00500000 - 00507000 MPRSERV.DLL 4.10.2222 Microsoft Corporation Multinet Router C: \WINDOWS\SYSTEM\MPRSERV.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fad0000 - 7faf6000 NETAPI32.DLL 4.10.1998 Microsoft Corporation 32-bit network API DLL C: \WINDOWS\SYSTEM\NETAPI32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7f990000 - 7f995000 NETBIOS.DLL C:\WINDOWS\SYSTEM\NETBIOS. DLL 4/23/99 4:37:39 PM GMT 7f840000 - 7f848000 RNR20.DLL 4.10.2222 Microsoft Corporation Windows Socket2 NameSpace DLL C: \WINDOWS\SYSTEM\RNR20.DLL 4/23/99 4:38:44 PM GMT Microsoft(R) Windows(R) Operating System 783c0000 - 783cf000 MSAFD.DLL 4.10.1998 Microsoft Corporation Microsoft Windows Sockets 2.0 Service Provider C:\WINDOWS\SYSTEM\MSAFD.DLL 4/23/99 4: 38:11 PM GMT Microsoft(R) Windows(R) Operating System 7b410000 - 7b41b000 RPCLTSCM.DLL 4.71.2900 Microsoft Corporation Remote Process Control LTSCM DLL C: \WINDOWS\SYSTEM\RPCLTSCM.DLL 4/23/99 4:38:45 PM GMT Microsoft® Windows® Operating System 78320000 - 7832a000 WSOCK32.DLL 4.10.1998 Microsoft Corporation BSD Socket API for Windows C: \WINDOWS\SYSTEM\WSOCK32.DLL 4/23/99 4:39:14 PM GMT Microsoft(R) Windows(R) Operating System 75fa0000 - 75faa000 MSWSOCK.DLL 4.10.2222 Microsoft Corporation Microsoft WinSock Extension APIs C: \WINDOWS\SYSTEM\MSWSOCK.DLL 4/23/99 4:38:30 PM GMT Microsoft(R) Windows(R) Operating System 794d0000 - 794e5000 WS2_32.DLL 4.10.2222 Microsoft Corporation Windows Socket 2.0 32-Bit DLL C: \WINDOWS\SYSTEM\WS2_32.DLL 4/23/99 4:39:13 PM GMT Microsoft(R) Windows(R) Operating System 76000000 - 76012000 WS2HELP.DLL 4.10.1998 Microsoft Corporation Windows Socket 2.0 Helper for Windows 98 C:\WINDOWS\SYSTEM\WS2HELP.DLL 4/23/99 4: 39:13 PM GMT Microsoft(R) Windows(R) Operating System 75fe0000 - 75fe6000 DIGEST.DLL 6.00.2800.1106 Microsoft Corporation Digest SSPI Authentication Package C: \WINDOWS\SYSTEM\DIGEST.DLL 8/29/02 11:21:08 AM GMT Microsoft® Windows® Operating System 007a0000 - 007b0000 MSNSSPC.DLL 6.00.7753 Microsoft Corporation MSN Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSNSSPC.DLL 4/23/99 4:38:21 PM GMT Microsoft® Internet Services 7a210000 - 7a22f000 MSAPSSPC.DLL 5.00.7729 Microsoft Corporation DPA Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSAPSSPC.DLL 4/23/99 4:38:11 PM GMT Microsoft® Internet Services 7b3f0000 - 7b401000 MSVCRT40.DLL 4.22.0000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT40.DLL 4/23/99 4:38:29 PM GMT Microsoft® Visual C++ 79660000 - 796b5000 SECUR32.DLL 4.10.2222 Microsoft Corporation Microsoft Win32 Security Services C: \WINDOWS\SYSTEM\SECUR32.DLL 4/23/99 4:37:39 PM GMT Microsoft(R) Windows(R) Operating System 7f870000 - 7f87a000 RPCSS.EXE 4.71.2900 Microsoft Corporation Distributed COM Services C: \WINDOWS\SYSTEM\RPCSS.EXE 9/1/98 6:18:39 PM GMT Microsoft(R) Windows NT(TM) Operating System 01000000 - 01005000 MSVCRT20.DLL 2.11.000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT20.DLL 4/23/99 4:37:36 PM GMT Microsoft® Visual C++ 7fc30000 - 7fc75000 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 22:13 Message: Logged In: YES user_id=31435 Kurt, which versions of Windows and winsock.dll are you using? I continue to be unable to reproduce any problem here, and there have been no other reports of this despite thousands of Python programs using sockets on Windows for a decade. I have to conclude there's something unique in your setup. FYI, sometimes virus scanners and/or "personal firewalls" cause bizarre crashes during startup or shutdown. Are you running one (or more) of those? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 20:29 Message: Logged In: YES user_id=816888 I have a working fix for this problem, but the code is a fairly ugly hack. (A terrible thing to do to such a well organized codebase). 1. I exported a fini_socket() function from the PYD DLL. 2. I cloned the dynamic lookup function to check for the optional fini_socket() name as well as the init_socket(). If found, I remember it in a global. 3. In PyImport_Cleanup() I call the fini_socket() routine (if present) before these modules start getting freed. 4. In NTInit() I add to a counter instead of using atexit() 5. fini_socket() calls NTcleanup(), which simply calls WSACleanup 'counter' times to release the winsock DLL. This works, so now I can go on with my Python study. If anyone wants my hack code, just email me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 15:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 13:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 11:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Mon Jul 7 11:08:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 03:08:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-765903 ] bundlebuilder Info.plist files. Message-ID: Bugs item #765903, was opened at 2003-07-04 14:11 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: bundlebuilder Info.plist files. Initial Comment: Spotted by Edward Moy: ----------- 8) In BuildApplet.app/Contents/Info.plist, the CFBundleIdentifier needs to be a reverse-dns format (org.python.BuildApplet; in the WWDC preview, I have accidentally made it com.apple.BuildApplet). It also needs a CFBundleShortVersionString entry (I just used 1.0 for the WWDC preview). ------------ This needs a couple of changes, really: - bundlebuilder needs a way to specify these, plus sensible defaults. - the same for BuildApplet, when it calls bundlebuilder - Mac/OSX/Makefile needs to be adapted to use the new options. If you don't have the time to fix all of these please go as far as you can and reassign back to me. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-07 12:08 Message: Logged In: YES user_id=45365 Yes, I guess you're right. bundlebuilder should put valid default values in the plist files and that's it. Our applets will just have to come with their own plist files. So I'd say rip out the bundle_id option but put in a valid bundle ID and version number, and please either create plist files for our applets (and use these in Mac/OSX/ Makefile) or put in a bug report to that effect on my name. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-04 18:24 Message: Logged In: YES user_id=92689 Oops, you're right, I was too fast: I indeed didn't do BuildApplet or CFBundleShortVersionString. I'm worried about bundlebuilder feature-bloat, though: the net -- bundle-id flag is only a convenience to avoid creating an explicit plist. BuildApplet could easily create the plist "manually", and that would in fact be the more general solution, so I'm tempted to rip --bundle-id out again. Do all bundles *have* to specify CFBundleShortVersionString? If so, should bundlebuilder simply use "1.0" if it's not specified in the plist? ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-04 17:29 Message: Logged In: YES user_id=45365 I got the impression that you only did step 1 (bundlebuilder), not BuildApplet and Mac/OSX/Makefile, right? Also, did you do the CFBundleShortVersionString bit too? Again, reassign to me if you don't feel like hacking this. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-04 16:22 Message: Logged In: YES user_id=92689 Done, except they're named bundle_id and --bundle-id. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-04 15:28 Message: Logged In: YES user_id=92689 IMO the sensible default is what we have now (and what a _lot_ of commercial apps do as well, just have a look at ~/Library/ Preferences/*.plist). For the applets shipping with Python it would indeed be much better if the bundle id started with "org.python.". I suggest to add a --bundle-identifier switch (and a bundle_identifier kwarg). I will do this unless you disagree. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765903&group_id=5470 From noreply@sourceforge.net Mon Jul 7 13:08:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 05:08:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-767089 ] problem loading shared libraries from an extension module Message-ID: Bugs item #767089, was opened at 2003-07-07 17: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=767089&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Amitay Isaacs (amitay) Assigned to: Nobody/Anonymous (nobody) Summary: problem loading shared libraries from an extension module Initial Comment: I am trying to build an extension module for libdbi (c library for DB interface). Attached is the simple module code. This code works fine with python version 1.5.2. But does not work with python version 2.2.2 and 2.2.3. I have tested on following platforms. python 1.5.2 (redhat linux 7.3) python 2.2 (redhat linux 7.3) python 2.2.2 (redhat linux 9) python 2.2.3 (redhat linux 9 - rpms for redhat 9 on python site) The problem is in the dbi_initialize() call which actually loads the correct database access module (e.g. mysql or postgresql) based on set options. In this dbi_initialize() call, dlopen() is called to load the specific DB driver library with RTLD_NOW flag. This calls fails on python2 on all the platforms mentioned above. Whereas there is no problem with python 1.5.2. Has there been any change in the way modules are loaded which will affect the shared libraries being loaded in those modules? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767089&group_id=5470 From noreply@sourceforge.net Mon Jul 7 13:52:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 05:52:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http Message-ID: Bugs item #767111, was opened at 2003-07-07 22:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: AttributeError thrown by urllib.open_http Initial Comment: In 2.3b2, looks like an error condition isn't being picked up on line 300 or 301 of urllib.py. The code that triggered this traceback was simply: url = urllib.urlopen(action, data) Traceback (most recent call last): File "autospamrep.py", line 170, in ? current_page = handle_spamcop_page(current_page) File "autospamrep.py", line 140, in handle_spamcop_page url = urllib.urlopen(action, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 78, in urlopen return opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 183, in open return getattr(self, name)(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 308, in open_http return self.http_error(url, fp, errcode, errmsg, headers, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 From noreply@sourceforge.net Mon Jul 7 15:03:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 07:03:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-767150 ] socket.inet_aton on 64bit platform Message-ID: Bugs item #767150, was opened at 2003-07-07 16: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=767150&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: socket.inet_aton on 64bit platform Initial Comment: Hi, socket.inet_aton() returns an 8 byte string when built on Linux/IA64. This should be 4 bytes on all architectures. Example: >>> import socket >>> socket.inet_aton('192.168.2.1') '\xc0\xa8\x02\x01\x00\x00\x00\x00' The bug is caused by Modules/socketmodule.c using sizeof(unsinged long) when constructing the string, which is 8 bytes on Linux/IA64. The bug seems to be fixed in Python 2.3 in the case struct in_addr is available. Otherwise it still uses an unsigned long. Geert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767150&group_id=5470 From noreply@sourceforge.net Mon Jul 7 15:20:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 07:20:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-763032 ] tut/contents.html does not exist Message-ID: Bugs item #763032, was opened at 2003-06-30 02:59 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 6 Submitted By: Matthias Klose (doko) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: tut/contents.html does not exist Initial Comment: 2.2.3 and 2.3: generating the html tutorial doesn't create tut/contents.html, although it's referenced by other tut/* pages. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-07 10:20 Message: Logged In: YES user_id=3066 Ok, thanks for checking again. Closing this report. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-07-06 03:59 Message: Logged In: YES user_id=60903 I was wrong. The fix is in 2.3b2 ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-01 09:44 Message: Logged In: YES user_id=3066 I don't see this. Can you tell me exactly which file you downloaded? The full filename and where you found it would both help. Also, the name of a file that contains the bogus link. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-30 18:01 Message: Logged In: YES user_id=3066 Re-opened so I won't forget to look at this later; hopefully tonight. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-06-30 17:09 Message: Logged In: YES user_id=60903 I'm confused. This is what I got from the 2.3b2 tarball ... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-06-30 13:13 Message: Logged In: YES user_id=3066 This was fixed in time for the Python 2.3 beta 2 release; please update your copy of the formatting tools. In particular, Doc/perl/l2hinit.perl needs to be updated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763032&group_id=5470 From noreply@sourceforge.net Mon Jul 7 16:39:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 08:39:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-767163 ] problem loading shared libraries from an extension module Message-ID: Bugs item #767163, was opened at 2003-07-07 21:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767163&group_id=5470 Category: Extension Modules Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Amitay Isaacs (amitay) Assigned to: Nobody/Anonymous (nobody) Summary: problem loading shared libraries from an extension module Initial Comment: I am trying to build an extension module for libdbi (c library for DB interface). Attached is the simple module code. This code works fine with python version 1.5.2. But does not work with python version 2.2.2 and 2.2.3. I have tested on following platforms. python 1.5.2 (redhat linux 7.3) python 2.2 (redhat linux 7.3) python 2.2.2 (redhat linux 9) python 2.2.3 (redhat linux 9 - rpms for redhat 9 on python site) The problem is in the dbi_initialize() call which actually loads the correct database access module (e.g. mysql or postgresql) based on set options. In this dbi_initialize() call, dlopen() is called to load the specific DB driver library with RTLD_NOW flag. This calls fails on python2 on all the platforms mentioned above. Whereas there is no problem with python 1.5.2. Has there been any change in the way modules are loaded which will affect the shared libraries being loaded in those modules? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767163&group_id=5470 From noreply@sourceforge.net Mon Jul 7 16:57:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 08:57:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-767163 ] problem loading shared libraries from an extension module Message-ID: Bugs item #767163, was opened at 2003-07-07 11:39 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767163&group_id=5470 Category: Extension Modules Group: Python 2.2.2 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Amitay Isaacs (amitay) Assigned to: Nobody/Anonymous (nobody) Summary: problem loading shared libraries from an extension module Initial Comment: I am trying to build an extension module for libdbi (c library for DB interface). Attached is the simple module code. This code works fine with python version 1.5.2. But does not work with python version 2.2.2 and 2.2.3. I have tested on following platforms. python 1.5.2 (redhat linux 7.3) python 2.2 (redhat linux 7.3) python 2.2.2 (redhat linux 9) python 2.2.3 (redhat linux 9 - rpms for redhat 9 on python site) The problem is in the dbi_initialize() call which actually loads the correct database access module (e.g. mysql or postgresql) based on set options. In this dbi_initialize() call, dlopen() is called to load the specific DB driver library with RTLD_NOW flag. This calls fails on python2 on all the platforms mentioned above. Whereas there is no problem with python 1.5.2. Has there been any change in the way modules are loaded which will affect the shared libraries being loaded in those modules? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-07 11:57 Message: Logged In: YES user_id=33168 Duplicate of 767089 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767163&group_id=5470 From noreply@sourceforge.net Mon Jul 7 17:29:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 09:29:07 -0700 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 12:39 Message generated for change (Comment added) made by joshhoyt 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: Josh Hoyt (joshhoyt) Date: 2003-07-07 09: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-06 22: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-06 19: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 02: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@sourceforge.net Mon Jul 7 18:18:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 10:18:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-767228 ] Is pickle (cPickle) broken in 2.3b2 ? Message-ID: Bugs item #767228, was opened at 2003-07-07 17:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767228&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Mirai (gmirai) Assigned to: Nobody/Anonymous (nobody) Summary: Is pickle (cPickle) broken in 2.3b2 ? Initial Comment: The following code works correctly with 2.3b1 (on MacOS X), but it throws KeyError: __getinitargs__ with 2.3b2 : -------------------------------------------- #!/usr/bin/env python import cPickle as c class Style: def __init__(self): self.d = {} def __setitem__(self, key, value): self.d["d_"+key]=value def __getattr__(self, key): if key.startswith("d_"): return self.d[key] else: return self.__dict__[key] s = Style() s["A"] = "B" print s.d_A print c.dumps(s) -------------------------------------------- The problem shows with any class that should override __getattr__ attribute. So it seems that pickle is broken in the new release ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767228&group_id=5470 From noreply@sourceforge.net Mon Jul 7 18:31:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 10:31:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-767228 ] Pickle (cPickle) __getinitargs__ problem in 2.3b2 ? Message-ID: Bugs item #767228, was opened at 2003-07-07 17:18 Message generated for change (Settings changed) made by gmirai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767228&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Mirai (gmirai) Assigned to: Nobody/Anonymous (nobody) >Summary: Pickle (cPickle) __getinitargs__ problem in 2.3b2 ? Initial Comment: The following code works correctly with 2.3b1 (on MacOS X), but it throws KeyError: __getinitargs__ with 2.3b2 : -------------------------------------------- #!/usr/bin/env python import cPickle as c class Style: def __init__(self): self.d = {} def __setitem__(self, key, value): self.d["d_"+key]=value def __getattr__(self, key): if key.startswith("d_"): return self.d[key] else: return self.__dict__[key] s = Style() s["A"] = "B" print s.d_A print c.dumps(s) -------------------------------------------- The problem shows with any class that should override __getattr__ attribute. So it seems that pickle is broken in the new release ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767228&group_id=5470 From noreply@sourceforge.net Mon Jul 7 18:49:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 10:49:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-715063 ] bsddb.first()/next() raise undocumented exception Message-ID: Bugs item #715063, was opened at 2003-04-03 23:03 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Christian Stork (cst) Assigned to: Gregory P. Smith (greg) Summary: bsddb.first()/next() raise undocumented exception Initial Comment: bsddb object's first() & next() methods raise an undocumented exception. Wouldn't returning None make much more sense? And shouldn't this be documented? Python 2.3a2+ (#2, Mar 21 2003, 22:13:05) [GCC 3.2.3 20030316 (Debian prerelease)] on linux2 >>> import bsddb >>> h.bsddb.hashopen("testdb") >>> h.first() ------------------------------------------------------------ Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/bsddb/__init__.py", line 134, in first rv = self.dbc.first() DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/ data pair found') Note: The same exception appeared for the equivalent dbhash methods. But I assume this should be fixed if this bug is fixed. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-07 13:49 Message: Logged In: YES user_id=12800 Greg, what about cursor.set() -- I don't think this follows set_get_returns_none() does it? I wonder if it should. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 20:01 Message: Logged In: YES user_id=413 DBNotFoundError derives from KeyError. The old bsddb library also raised KeyError on first/last/next calls when there was no more data rather than returning None so that interface cannot be changed. (I agree, returning None would make more sense; but I can't break the old interface). The new pybsddb interface's DB and DBEnv set_get_returns_none method does allow you to control this behaviour. If you are using the old style bsddb interface then you do not have access to the DBEnv before the DB object is created (DB objects inherit the flag setting from the DBEnv when they are created) so you'll need to call set_get_returns_none on the DB object itself: import bsddb # python 2.3 bsddb (aka bsddb3 or pybsddb) hdb = bsddb.hashopen("myhash", 'c') hdb.db.set_get_returns_none(1) # will only work on python 2.3 / pybsddb spam = hdb.first() while spam: spam = hdb.next() # notice there were no errors. I've looked at the code for first/last/prev/get and they all use the same internal DBCursor_get wrapper that obeys the set_get_returns_none flag so that you can write simple "foo = hdb.first(); while not foo: foo = hdb.next()" code. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 19:24 Message: Logged In: YES user_id=413 i'm taking a look. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-07 18:46 Message: Logged In: YES user_id=12800 pybsddb has this option to return None from cursor.get() methods instead of raising DBNotFoundError. The DBEnv method set_get_returns_none() can be used to change the behavior, although the default is to return None. I agree that this is very handy! I suppose .first() and .last() should perhaps honor this config as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 From noreply@sourceforge.net Mon Jul 7 19:05:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 11:05:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 07:32 Message generated for change (Comment added) made by grittkmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 7 Submitted By: Kurt Grittner (grittkmg) Assigned to: Mark Hammond (mhammond) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 13:05 Message: Logged In: YES user_id=816888 From: "Eugene Gershnik [SDK MVP]" References: <6hvigvgnlsqhihobl06jt1edjfsv7r4pja@4ax.com> Subject: Re: WSAStartup and WSACleanup from within a DLL Date: Mon, 7 Jul 2003 10:26:25 -0700 Lines: 24 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Newsgroups: microsoft.public.win32.programmer.networks NNTP-Posting-Host: dsl093-033-235.snd1.dsl.speakeasy.net 66.93.33.235 Path: TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl Xref: TK2MSFTNGP08.phx.gbl microsoft.public.win32. programmer.networks:43932 It is in general a bad idea. atexit() handlers are running from within DLL_PROCESS_DETACH notification and this is a bad place to clean up other DLLs. See remarks to DllMain in MSDN for details. Note that it is also a bad idea to use C++ global or static objects to startup/cleanup winsock since those als rely on atexit() for destruction. The best way to init winsock for your DLL is to have something like MyDllInit() and MyDllTerm() functions that should be called be the user of the DLL. Eugene Kurt Grittner wrote: > Hello Group, > > If you call all of your socket functions from within a DLL, and you > do the WSAStartup() inside the DLL, is it legal to then have your > WSACleanup() run via atexit(StaticFunctionInDLL)? I am getting > weird behavior (GPF) on someone else's program when they do this. > The WSACleanup ends up getting called from crt0dat. Any Opinions? > > Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 04:34 Message: Logged In: YES user_id=816888 Here is a small windows project that causes the error for me on my faster machines. I will try it on a bunch of other machines. badsock good Runs it the good way badsock bad or just plain badsock Causes the error for me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 01:13 Message: Logged In: YES user_id=816888 Well, Python is new to me, but Win32 isn't. My theory for why it fails is simply that the program breaks the rules and creates a window for failure. On my system the window is large. On yours, the window is smaller. This is a machine with lots of memory. (AMD XP2000, 512MB RAM). It has a new hard drive with an on board 8MB cache. Things happen fast on this machine. This single fact could explain why the failure condition always wins the race for me. The machines at work (which also fail) are similar. Who puts win98SE on a brand new machine these days? Hmmm... maybe not too many people. I can turn your argument around... I have dozens of network programs running on this machine, many of which I wrote, none of which play fast-and-loose with threaded-DLL's, all of which work. Python is the only network program that fails. It fails every single time. I luckily have access to the source, so I can find the bug and fix it. Great! The wonders of open source. Well, anyhow, I was only trying to lend a hand. Python looks promising. I am looking at it as a potential replacement for VB/ActiveX. I am going to try this on some older, slower machines. Also, I will attempt to code a demo program that reproduces the bad behavior by duplicating the steps taken in the socketmodule, and hopefully also duplicating the error on more machines. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 23:26 Message: Logged In: YES user_id=31435 Mark, can you take a look at this? If you agree the design is hosed, it would be good to fix it before 2.3r1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 23:21 Message: Logged In: YES user_id=31435 You're trying too hard . I'm not arguing about the design (for one thing, it's not my design, and I don't know anything about it), I'm wondering both why I can't reproduce a problem, and especially why no other report of this has ever been made. You surely don't believe you're the only programmer to try sockets in Python on Windows, right? I also tried it under an up-to-date Win98SE, also with MSVC 6 and all current IE 6 patches. Indeed, that's the machine I've built the PythonLabs Windows installer *on* for the last two years. No problem. Everyone who has ever run the Python test suite on Windows has exercised sockets on Windows, and so has anyone who has ever run Zope on Windows, etc. It may indeed be a bit of Rocket Science if you don't have a theory for why it fails only when you run it! The reason I'm keen to know is that only someone who can see the problem can test a putative fix (and so confirm-- or refute --that the problem goes away). ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 23:00 Message: Logged In: YES user_id=816888 Umm, this is not rocket science. WSACleanup() is being called in the wrong context. Startup is called in a DLL context. That puts the info in Thread Local Storage (TLS). The DLL Is allowed to unload with an atexit() pointer still pending to it. This is bad design. You should always call startup/cleanup in pairs and in the same thread context. As I said before this happens on every win98SE machine that I have tried it on. I have no firewall or virus scanner. This is a fairly recent installation of win98 with all of the MS updates for I.E. Apart from that, the most unusual thing is the presence of the VisualStudio 6.0 suite of programs. I can do a new install of win98SE on an old machine, just out of curiosity, but you only have to read this web site to see that this design for startup/cleanup calls is a recipie for disaster: http://support.microsoft.com/default.aspx?scid=http: //support.microsoft.com:80/support/kb/articles/Q237/5/72. ASP&NoWebContent=1 Here is a list of some of the modules running on my machine: USER32.DLL 4.10.2227 Microsoft Corporation Win32 USER32 core component C:\WINDOWS\SYSTEM\USER32. DLL 4/21/00 3:33:18 PM GMT Microsoft(R) Windows(R) Operating System bfc00000 - bfc11000 GDI32.DLL 4.10.1998 Microsoft Corporation Win32 GDI core component C:\WINDOWS\SYSTEM\GDI32. DLL 4/23/98 4:24:18 AM GMT Microsoft(R) Windows(R) Operating System bff20000 - bff46000 ADVAPI32.DLL 4.80.1675 Microsoft Corporation Win32 ADVAPI32 core component C: \WINDOWS\SYSTEM\ADVAPI32.DLL 4/23/99 4:37:33 PM GMT Microsoft(R) Windows(R) Operating System bfe80000 - bfe90000 KERNEL32.DLL 4.10.2222 Microsoft Corporation Win32 Kernel core component C: \WINDOWS\SYSTEM\KERNEL32.DLL 4/23/99 12:45:39 AM GMT Microsoft(R) Windows(R) Operating System bff70000 - bffe3000 MPR.DLL 4.10.1998 Microsoft Corporation WIN32 Network Interface DLL C:\WINDOWS\SYSTEM\MPR. DLL 4/23/99 4:37:36 PM GMT Microsoft(R) Windows(R) Operating System 7fbf0000 - 7fbfe000 MSNP32.DLL 4.10.2222 Microsoft Corporation Network provider for Microsoft networks C:\WINDOWS\SYSTEM\MSNP32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fb20000 - 7fb34000 MSNET32.DLL 4.10.2224 Microsoft Corporation Microsoft 32-bit Network API Library C: \WINDOWS\SYSTEM\MSNET32.DLL 11/12/99 4:15:15 AM GMT Microsoft(R) Windows(R) Operating System 7f300000 - 7f313000 MPREXE.EXE 4.10.1998 Microsoft Corporation WIN32 Network Interface Service Process C:\WINDOWS\SYSTEM\MPREXE.EXE 4/23/98 2:19:38 AM GMT Microsoft(R) Windows(R) Operating System 00500000 - 00507000 MPRSERV.DLL 4.10.2222 Microsoft Corporation Multinet Router C: \WINDOWS\SYSTEM\MPRSERV.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fad0000 - 7faf6000 NETAPI32.DLL 4.10.1998 Microsoft Corporation 32-bit network API DLL C: \WINDOWS\SYSTEM\NETAPI32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7f990000 - 7f995000 NETBIOS.DLL C:\WINDOWS\SYSTEM\NETBIOS. DLL 4/23/99 4:37:39 PM GMT 7f840000 - 7f848000 RNR20.DLL 4.10.2222 Microsoft Corporation Windows Socket2 NameSpace DLL C: \WINDOWS\SYSTEM\RNR20.DLL 4/23/99 4:38:44 PM GMT Microsoft(R) Windows(R) Operating System 783c0000 - 783cf000 MSAFD.DLL 4.10.1998 Microsoft Corporation Microsoft Windows Sockets 2.0 Service Provider C:\WINDOWS\SYSTEM\MSAFD.DLL 4/23/99 4: 38:11 PM GMT Microsoft(R) Windows(R) Operating System 7b410000 - 7b41b000 RPCLTSCM.DLL 4.71.2900 Microsoft Corporation Remote Process Control LTSCM DLL C: \WINDOWS\SYSTEM\RPCLTSCM.DLL 4/23/99 4:38:45 PM GMT Microsoft® Windows® Operating System 78320000 - 7832a000 WSOCK32.DLL 4.10.1998 Microsoft Corporation BSD Socket API for Windows C: \WINDOWS\SYSTEM\WSOCK32.DLL 4/23/99 4:39:14 PM GMT Microsoft(R) Windows(R) Operating System 75fa0000 - 75faa000 MSWSOCK.DLL 4.10.2222 Microsoft Corporation Microsoft WinSock Extension APIs C: \WINDOWS\SYSTEM\MSWSOCK.DLL 4/23/99 4:38:30 PM GMT Microsoft(R) Windows(R) Operating System 794d0000 - 794e5000 WS2_32.DLL 4.10.2222 Microsoft Corporation Windows Socket 2.0 32-Bit DLL C: \WINDOWS\SYSTEM\WS2_32.DLL 4/23/99 4:39:13 PM GMT Microsoft(R) Windows(R) Operating System 76000000 - 76012000 WS2HELP.DLL 4.10.1998 Microsoft Corporation Windows Socket 2.0 Helper for Windows 98 C:\WINDOWS\SYSTEM\WS2HELP.DLL 4/23/99 4: 39:13 PM GMT Microsoft(R) Windows(R) Operating System 75fe0000 - 75fe6000 DIGEST.DLL 6.00.2800.1106 Microsoft Corporation Digest SSPI Authentication Package C: \WINDOWS\SYSTEM\DIGEST.DLL 8/29/02 11:21:08 AM GMT Microsoft® Windows® Operating System 007a0000 - 007b0000 MSNSSPC.DLL 6.00.7753 Microsoft Corporation MSN Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSNSSPC.DLL 4/23/99 4:38:21 PM GMT Microsoft® Internet Services 7a210000 - 7a22f000 MSAPSSPC.DLL 5.00.7729 Microsoft Corporation DPA Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSAPSSPC.DLL 4/23/99 4:38:11 PM GMT Microsoft® Internet Services 7b3f0000 - 7b401000 MSVCRT40.DLL 4.22.0000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT40.DLL 4/23/99 4:38:29 PM GMT Microsoft® Visual C++ 79660000 - 796b5000 SECUR32.DLL 4.10.2222 Microsoft Corporation Microsoft Win32 Security Services C: \WINDOWS\SYSTEM\SECUR32.DLL 4/23/99 4:37:39 PM GMT Microsoft(R) Windows(R) Operating System 7f870000 - 7f87a000 RPCSS.EXE 4.71.2900 Microsoft Corporation Distributed COM Services C: \WINDOWS\SYSTEM\RPCSS.EXE 9/1/98 6:18:39 PM GMT Microsoft(R) Windows NT(TM) Operating System 01000000 - 01005000 MSVCRT20.DLL 2.11.000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT20.DLL 4/23/99 4:37:36 PM GMT Microsoft® Visual C++ 7fc30000 - 7fc75000 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 22:13 Message: Logged In: YES user_id=31435 Kurt, which versions of Windows and winsock.dll are you using? I continue to be unable to reproduce any problem here, and there have been no other reports of this despite thousands of Python programs using sockets on Windows for a decade. I have to conclude there's something unique in your setup. FYI, sometimes virus scanners and/or "personal firewalls" cause bizarre crashes during startup or shutdown. Are you running one (or more) of those? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 20:29 Message: Logged In: YES user_id=816888 I have a working fix for this problem, but the code is a fairly ugly hack. (A terrible thing to do to such a well organized codebase). 1. I exported a fini_socket() function from the PYD DLL. 2. I cloned the dynamic lookup function to check for the optional fini_socket() name as well as the init_socket(). If found, I remember it in a global. 3. In PyImport_Cleanup() I call the fini_socket() routine (if present) before these modules start getting freed. 4. In NTInit() I add to a counter instead of using atexit() 5. fini_socket() calls NTcleanup(), which simply calls WSACleanup 'counter' times to release the winsock DLL. This works, so now I can go on with my Python study. If anyone wants my hack code, just email me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 15:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 13:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 11:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Mon Jul 7 19:56:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 11:56:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-715063 ] bsddb.first()/next() raise undocumented exception Message-ID: Bugs item #715063, was opened at 2003-04-03 20:03 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Christian Stork (cst) Assigned to: Gregory P. Smith (greg) Summary: bsddb.first()/next() raise undocumented exception Initial Comment: bsddb object's first() & next() methods raise an undocumented exception. Wouldn't returning None make much more sense? And shouldn't this be documented? Python 2.3a2+ (#2, Mar 21 2003, 22:13:05) [GCC 3.2.3 20030316 (Debian prerelease)] on linux2 >>> import bsddb >>> h.bsddb.hashopen("testdb") >>> h.first() ------------------------------------------------------------ Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/bsddb/__init__.py", line 134, in first rv = self.dbc.first() DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/ data pair found') Note: The same exception appeared for the equivalent dbhash methods. But I assume this should be fixed if this bug is fixed. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-07-07 11:56 Message: Logged In: YES user_id=413 Looking in the code, no, none of the DBCursor set* methods follow set_get_returns_none() to not raise an exception. The documentation for set_get_returns_none implies that they should as they're all cursor "get" methods. All of the set methods normally return tuples of (key, data) rather than a single value. If we modify them to return None rather than raise a DBNotFoundError it makes for an annoying interface because it wouldn't always return a tuple. I'm inclined to leave the set methods as they are and fix the set_get_returns_none() documentation unless someone can come up with good examples why it should be different. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-07 10:49 Message: Logged In: YES user_id=12800 Greg, what about cursor.set() -- I don't think this follows set_get_returns_none() does it? I wonder if it should. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 17:01 Message: Logged In: YES user_id=413 DBNotFoundError derives from KeyError. The old bsddb library also raised KeyError on first/last/next calls when there was no more data rather than returning None so that interface cannot be changed. (I agree, returning None would make more sense; but I can't break the old interface). The new pybsddb interface's DB and DBEnv set_get_returns_none method does allow you to control this behaviour. If you are using the old style bsddb interface then you do not have access to the DBEnv before the DB object is created (DB objects inherit the flag setting from the DBEnv when they are created) so you'll need to call set_get_returns_none on the DB object itself: import bsddb # python 2.3 bsddb (aka bsddb3 or pybsddb) hdb = bsddb.hashopen("myhash", 'c') hdb.db.set_get_returns_none(1) # will only work on python 2.3 / pybsddb spam = hdb.first() while spam: spam = hdb.next() # notice there were no errors. I've looked at the code for first/last/prev/get and they all use the same internal DBCursor_get wrapper that obeys the set_get_returns_none flag so that you can write simple "foo = hdb.first(); while not foo: foo = hdb.next()" code. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 16:24 Message: Logged In: YES user_id=413 i'm taking a look. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-07 15:46 Message: Logged In: YES user_id=12800 pybsddb has this option to return None from cursor.get() methods instead of raising DBNotFoundError. The DBEnv method set_get_returns_none() can be used to change the behavior, although the default is to return None. I agree that this is very handy! I suppose .first() and .last() should perhaps honor this config as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 From noreply@sourceforge.net Mon Jul 7 20:11:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 12:11:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-766696 ] gcc-3.3: dereferencing type-punned pointer Message-ID: Bugs item #766696, was opened at 2003-07-06 16:04 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766696&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) >Assigned to: Martin v. Löwis (loewis) Summary: gcc-3.3: dereferencing type-punned pointer Initial Comment: Building with gcc-3.3 leads to about 250 warnings 263 dereferencing type-punned pointer will break strict-aliasing rules Include/intobject.h:#define Py_True ((PyObject *) &_Py_TrueStruct) although the test results look good. Please add -fno-strict-aliasing to the compiler flags, when compiling with gcc-3.3 or up. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-07-07 11:16 Message: Logged In: YES user_id=60903 attached. if correct, please apply to the branch as well. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 07:03 Message: Logged In: YES user_id=21627 Can you provide a patch for that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766696&group_id=5470 From noreply@sourceforge.net Mon Jul 7 20:14:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 12:14:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-767228 ] Pickle (cPickle) __getinitargs__ problem in 2.3b2 ? Message-ID: Bugs item #767228, was opened at 2003-07-07 17:18 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767228&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Mirai (gmirai) >Assigned to: Jeremy Hylton (jhylton) Summary: Pickle (cPickle) __getinitargs__ problem in 2.3b2 ? Initial Comment: The following code works correctly with 2.3b1 (on MacOS X), but it throws KeyError: __getinitargs__ with 2.3b2 : -------------------------------------------- #!/usr/bin/env python import cPickle as c class Style: def __init__(self): self.d = {} def __setitem__(self, key, value): self.d["d_"+key]=value def __getattr__(self, key): if key.startswith("d_"): return self.d[key] else: return self.__dict__[key] s = Style() s["A"] = "B" print s.d_A print c.dumps(s) -------------------------------------------- The problem shows with any class that should override __getattr__ attribute. So it seems that pickle is broken in the new release ? ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-07-07 19:14 Message: Logged In: YES user_id=31392 I probably broke something in change that catches only specific exceptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767228&group_id=5470 From noreply@sourceforge.net Mon Jul 7 20:39:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 12:39:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-715063 ] bsddb.first()/next() raise undocumented exception Message-ID: Bugs item #715063, was opened at 2003-04-03 23:03 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Christian Stork (cst) Assigned to: Gregory P. Smith (greg) Summary: bsddb.first()/next() raise undocumented exception Initial Comment: bsddb object's first() & next() methods raise an undocumented exception. Wouldn't returning None make much more sense? And shouldn't this be documented? Python 2.3a2+ (#2, Mar 21 2003, 22:13:05) [GCC 3.2.3 20030316 (Debian prerelease)] on linux2 >>> import bsddb >>> h.bsddb.hashopen("testdb") >>> h.first() ------------------------------------------------------------ Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/bsddb/__init__.py", line 134, in first rv = self.dbc.first() DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/ data pair found') Note: The same exception appeared for the equivalent dbhash methods. But I assume this should be fixed if this bug is fixed. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-07 15:39 Message: Logged In: YES user_id=12800 Greg, correct me if I'm wrong but cursor.next() already has the return value issue you point out, i.e. it can return None or a tuple. My pattern has been to do stuff like this: rec = c.first() while rec: key, val = rec rec = c.next() so it doesn't bother me too much if the cursor.set() method works the same way . I think the documentation of set_get_returns_none is correct and cursor.set() should be changed to follow those rules. I'm not too concerned with backward compatibility either because this is the common .set() idiom I use: try: rec = c.set('somekey') except db.DBNotFoundError: rec = None while rec: ... This code would not break by changing .set(), but I would be able to remove the try/except. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-07 14:56 Message: Logged In: YES user_id=413 Looking in the code, no, none of the DBCursor set* methods follow set_get_returns_none() to not raise an exception. The documentation for set_get_returns_none implies that they should as they're all cursor "get" methods. All of the set methods normally return tuples of (key, data) rather than a single value. If we modify them to return None rather than raise a DBNotFoundError it makes for an annoying interface because it wouldn't always return a tuple. I'm inclined to leave the set methods as they are and fix the set_get_returns_none() documentation unless someone can come up with good examples why it should be different. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-07 13:49 Message: Logged In: YES user_id=12800 Greg, what about cursor.set() -- I don't think this follows set_get_returns_none() does it? I wonder if it should. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 20:01 Message: Logged In: YES user_id=413 DBNotFoundError derives from KeyError. The old bsddb library also raised KeyError on first/last/next calls when there was no more data rather than returning None so that interface cannot be changed. (I agree, returning None would make more sense; but I can't break the old interface). The new pybsddb interface's DB and DBEnv set_get_returns_none method does allow you to control this behaviour. If you are using the old style bsddb interface then you do not have access to the DBEnv before the DB object is created (DB objects inherit the flag setting from the DBEnv when they are created) so you'll need to call set_get_returns_none on the DB object itself: import bsddb # python 2.3 bsddb (aka bsddb3 or pybsddb) hdb = bsddb.hashopen("myhash", 'c') hdb.db.set_get_returns_none(1) # will only work on python 2.3 / pybsddb spam = hdb.first() while spam: spam = hdb.next() # notice there were no errors. I've looked at the code for first/last/prev/get and they all use the same internal DBCursor_get wrapper that obeys the set_get_returns_none flag so that you can write simple "foo = hdb.first(); while not foo: foo = hdb.next()" code. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 19:24 Message: Logged In: YES user_id=413 i'm taking a look. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-07 18:46 Message: Logged In: YES user_id=12800 pybsddb has this option to return None from cursor.get() methods instead of raising DBNotFoundError. The DBEnv method set_get_returns_none() can be used to change the behavior, although the default is to return None. I agree that this is very handy! I suppose .first() and .last() should perhaps honor this config as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 From noreply@sourceforge.net Mon Jul 7 22:10:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 14:10:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-767150 ] socket.inet_aton on 64bit platform Message-ID: Bugs item #767150, was opened at 2003-07-07 16:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767150&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Geert Jansen (geertj) Assigned to: Nobody/Anonymous (nobody) Summary: socket.inet_aton on 64bit platform Initial Comment: Hi, socket.inet_aton() returns an 8 byte string when built on Linux/IA64. This should be 4 bytes on all architectures. Example: >>> import socket >>> socket.inet_aton('192.168.2.1') '\xc0\xa8\x02\x01\x00\x00\x00\x00' The bug is caused by Modules/socketmodule.c using sizeof(unsinged long) when constructing the string, which is 8 bytes on Linux/IA64. The bug seems to be fixed in Python 2.3 in the case struct in_addr is available. Otherwise it still uses an unsigned long. Geert ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 23:10 Message: Logged In: YES user_id=21627 Can you try to come up with a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767150&group_id=5470 From noreply@sourceforge.net Mon Jul 7 22:23:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 14:23:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-767374 ] #define _XOPEN_SOURCE in pyconfig.h causes problems for AIX Message-ID: Bugs item #767374, was opened at 2003-07-07 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=767374&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tom Epperly (tepperly) Assigned to: Nobody/Anonymous (nobody) Summary: #define _XOPEN_SOURCE in pyconfig.h causes problems for AIX Initial Comment: I installed Python 2.3b1 on an AIX system. The following simple program fails to compile. This is an extremely simplified version of an #include problem that occurs in a larger code that includes Python C extension modules. epperly@aixbox[~]>cat test_prog.c #include #include int main(char argc, char **argv) { return 0; } epperly@aixbox[~]>!new newcc -Ipython/include/python2.3/ test_prog.c "python/include/python2.3/pyconfig.h", line 841.9: 1506-236 (W) Macro name _XOPEN_SOURCE has been redefined. "python/include/python2.3/pyconfig.h", line 841.9: 1506-358 (I) "_XOPEN_SOURCE" is defined on line 89 of /usr/include/standards.h. "/usr/include/wchar.h", line 290.68: 1506-046 (S) Syntax error. "/usr/include/wchar.h", line 293.68: 1506-046 (S) Syntax error. epperly@aixbox[~]>uname -a AIX aixbox 1 5 006008594C0 The main problem is that pyconfig.h #define's _XOPEN_SOURCE to 600 and wchar.h only does the right thing if _XOPEN_SOURCE is defined to be 500. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767374&group_id=5470 From noreply@sourceforge.net Mon Jul 7 22:45:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 14:45:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-766696 ] gcc-3.3: dereferencing type-punned pointer Message-ID: Bugs item #766696, was opened at 2003-07-06 16:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766696&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Martin v. Löwis (loewis) Summary: gcc-3.3: dereferencing type-punned pointer Initial Comment: Building with gcc-3.3 leads to about 250 warnings 263 dereferencing type-punned pointer will break strict-aliasing rules Include/intobject.h:#define Py_True ((PyObject *) &_Py_TrueStruct) although the test results look good. Please add -fno-strict-aliasing to the compiler flags, when compiling with gcc-3.3 or up. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 23:45 Message: Logged In: YES user_id=21627 For 2.3, this is better stored in BASECFLAGS. Fixed in configure 1.412 configure.in 1.423 For 2.2, I have applied your patch as configure 1.279.6.20 configure.in 1.288.6.20 ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-07-07 11:16 Message: Logged In: YES user_id=60903 attached. if correct, please apply to the branch as well. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 07:03 Message: Logged In: YES user_id=21627 Can you provide a patch for that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766696&group_id=5470 From noreply@sourceforge.net Mon Jul 7 22:47:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 14:47:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-767374 ] #define _XOPEN_SOURCE in pyconfig.h causes problems for AIX Message-ID: Bugs item #767374, was opened at 2003-07-07 23:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767374&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tom Epperly (tepperly) Assigned to: Nobody/Anonymous (nobody) Summary: #define _XOPEN_SOURCE in pyconfig.h causes problems for AIX Initial Comment: I installed Python 2.3b1 on an AIX system. The following simple program fails to compile. This is an extremely simplified version of an #include problem that occurs in a larger code that includes Python C extension modules. epperly@aixbox[~]>cat test_prog.c #include #include int main(char argc, char **argv) { return 0; } epperly@aixbox[~]>!new newcc -Ipython/include/python2.3/ test_prog.c "python/include/python2.3/pyconfig.h", line 841.9: 1506-236 (W) Macro name _XOPEN_SOURCE has been redefined. "python/include/python2.3/pyconfig.h", line 841.9: 1506-358 (I) "_XOPEN_SOURCE" is defined on line 89 of /usr/include/standards.h. "/usr/include/wchar.h", line 290.68: 1506-046 (S) Syntax error. "/usr/include/wchar.h", line 293.68: 1506-046 (S) Syntax error. epperly@aixbox[~]>uname -a AIX aixbox 1 5 006008594C0 The main problem is that pyconfig.h #define's _XOPEN_SOURCE to 600 and wchar.h only does the right thing if _XOPEN_SOURCE is defined to be 500. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 23:47 Message: Logged In: YES user_id=21627 This is not a bug in Python, but in your code. Python.h must be the first include file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767374&group_id=5470 From noreply@sourceforge.net Mon Jul 7 22:50:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 14:50:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-767374 ] #define _XOPEN_SOURCE in pyconfig.h causes problems for AIX Message-ID: Bugs item #767374, was opened at 2003-07-07 14:23 Message generated for change (Comment added) made by tepperly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767374&group_id=5470 Category: Build Group: Python 2.3 >Status: Open Resolution: Invalid Priority: 5 Submitted By: Tom Epperly (tepperly) Assigned to: Nobody/Anonymous (nobody) Summary: #define _XOPEN_SOURCE in pyconfig.h causes problems for AIX Initial Comment: I installed Python 2.3b1 on an AIX system. The following simple program fails to compile. This is an extremely simplified version of an #include problem that occurs in a larger code that includes Python C extension modules. epperly@aixbox[~]>cat test_prog.c #include #include int main(char argc, char **argv) { return 0; } epperly@aixbox[~]>!new newcc -Ipython/include/python2.3/ test_prog.c "python/include/python2.3/pyconfig.h", line 841.9: 1506-236 (W) Macro name _XOPEN_SOURCE has been redefined. "python/include/python2.3/pyconfig.h", line 841.9: 1506-358 (I) "_XOPEN_SOURCE" is defined on line 89 of /usr/include/standards.h. "/usr/include/wchar.h", line 290.68: 1506-046 (S) Syntax error. "/usr/include/wchar.h", line 293.68: 1506-046 (S) Syntax error. epperly@aixbox[~]>uname -a AIX aixbox 1 5 006008594C0 The main problem is that pyconfig.h #define's _XOPEN_SOURCE to 600 and wchar.h only does the right thing if _XOPEN_SOURCE is defined to be 500. ---------------------------------------------------------------------- >Comment By: Tom Epperly (tepperly) Date: 2003-07-07 14:50 Message: Logged In: YES user_id=94539 I set some environment variables that impact the configure run: CC=newcc CXX=newxlC F77=newxlf F90=newxlf90 -qsuffix=f=f90 CPP=gcc -E I am rerunning the test with Python2.3b2. Here is how I am invoking configure. ./configure --prefix=${HOME}/python23b2 --enable-shared --disable-ipv6 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 14:47 Message: Logged In: YES user_id=21627 This is not a bug in Python, but in your code. Python.h must be the first include file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767374&group_id=5470 From noreply@sourceforge.net Mon Jul 7 22:52:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 14:52:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-767374 ] #define _XOPEN_SOURCE in pyconfig.h causes problems for AIX Message-ID: Bugs item #767374, was opened at 2003-07-07 14:23 Message generated for change (Comment added) made by tepperly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767374&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Invalid Priority: 5 Submitted By: Tom Epperly (tepperly) Assigned to: Nobody/Anonymous (nobody) Summary: #define _XOPEN_SOURCE in pyconfig.h causes problems for AIX Initial Comment: I installed Python 2.3b1 on an AIX system. The following simple program fails to compile. This is an extremely simplified version of an #include problem that occurs in a larger code that includes Python C extension modules. epperly@aixbox[~]>cat test_prog.c #include #include int main(char argc, char **argv) { return 0; } epperly@aixbox[~]>!new newcc -Ipython/include/python2.3/ test_prog.c "python/include/python2.3/pyconfig.h", line 841.9: 1506-236 (W) Macro name _XOPEN_SOURCE has been redefined. "python/include/python2.3/pyconfig.h", line 841.9: 1506-358 (I) "_XOPEN_SOURCE" is defined on line 89 of /usr/include/standards.h. "/usr/include/wchar.h", line 290.68: 1506-046 (S) Syntax error. "/usr/include/wchar.h", line 293.68: 1506-046 (S) Syntax error. epperly@aixbox[~]>uname -a AIX aixbox 1 5 006008594C0 The main problem is that pyconfig.h #define's _XOPEN_SOURCE to 600 and wchar.h only does the right thing if _XOPEN_SOURCE is defined to be 500. ---------------------------------------------------------------------- >Comment By: Tom Epperly (tepperly) Date: 2003-07-07 14:52 Message: Logged In: YES user_id=94539 Requiring #include to be first is a regretable design decision that other software packages regretably also make. It makes interoperability a challenge. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2003-07-07 14:50 Message: Logged In: YES user_id=94539 I set some environment variables that impact the configure run: CC=newcc CXX=newxlC F77=newxlf F90=newxlf90 -qsuffix=f=f90 CPP=gcc -E I am rerunning the test with Python2.3b2. Here is how I am invoking configure. ./configure --prefix=${HOME}/python23b2 --enable-shared --disable-ipv6 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 14:47 Message: Logged In: YES user_id=21627 This is not a bug in Python, but in your code. Python.h must be the first include file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767374&group_id=5470 From noreply@sourceforge.net Mon Jul 7 22:54:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 14:54:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-767089 ] problem loading shared libraries from an extension module Message-ID: Bugs item #767089, was opened at 2003-07-07 14:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767089&group_id=5470 Category: Extension Modules >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Amitay Isaacs (amitay) Assigned to: Nobody/Anonymous (nobody) Summary: problem loading shared libraries from an extension module Initial Comment: I am trying to build an extension module for libdbi (c library for DB interface). Attached is the simple module code. This code works fine with python version 1.5.2. But does not work with python version 2.2.2 and 2.2.3. I have tested on following platforms. python 1.5.2 (redhat linux 7.3) python 2.2 (redhat linux 7.3) python 2.2.2 (redhat linux 9) python 2.2.3 (redhat linux 9 - rpms for redhat 9 on python site) The problem is in the dbi_initialize() call which actually loads the correct database access module (e.g. mysql or postgresql) based on set options. In this dbi_initialize() call, dlopen() is called to load the specific DB driver library with RTLD_NOW flag. This calls fails on python2 on all the platforms mentioned above. Whereas there is no problem with python 1.5.2. Has there been any change in the way modules are loaded which will affect the shared libraries being loaded in those modules? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 23:54 Message: Logged In: YES user_id=21627 I fail to see a bug in Python here. If dlopen fails, it is likely a bug in whoever calls dlopen, or in the dlopen implementation, not a bug in Python. Most likely, the problem is completely unrelated to Python. It would probably be useful to get the result of dlerror(3) after the call to dlopen. About the only "change" that might have any effect is that Redhat chose Python to use RTLD_GLOBAL when loading extension modules, whereas standard Python (all versions since after 1.5.1) use RTLD_LOCAL (i.e. nothing). This Redhat change has caused many problems in the past, so it got never incorporated into the standard distribution. Closing as third-party. If you can demonstrate a true bug, please submit a new report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767089&group_id=5470 From noreply@sourceforge.net Mon Jul 7 22:56:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 14:56:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-767374 ] #define _XOPEN_SOURCE in pyconfig.h causes problems for AIX Message-ID: Bugs item #767374, was opened at 2003-07-07 23:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767374&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Tom Epperly (tepperly) Assigned to: Nobody/Anonymous (nobody) Summary: #define _XOPEN_SOURCE in pyconfig.h causes problems for AIX Initial Comment: I installed Python 2.3b1 on an AIX system. The following simple program fails to compile. This is an extremely simplified version of an #include problem that occurs in a larger code that includes Python C extension modules. epperly@aixbox[~]>cat test_prog.c #include #include int main(char argc, char **argv) { return 0; } epperly@aixbox[~]>!new newcc -Ipython/include/python2.3/ test_prog.c "python/include/python2.3/pyconfig.h", line 841.9: 1506-236 (W) Macro name _XOPEN_SOURCE has been redefined. "python/include/python2.3/pyconfig.h", line 841.9: 1506-358 (I) "_XOPEN_SOURCE" is defined on line 89 of /usr/include/standards.h. "/usr/include/wchar.h", line 290.68: 1506-046 (S) Syntax error. "/usr/include/wchar.h", line 293.68: 1506-046 (S) Syntax error. epperly@aixbox[~]>uname -a AIX aixbox 1 5 006008594C0 The main problem is that pyconfig.h #define's _XOPEN_SOURCE to 600 and wchar.h only does the right thing if _XOPEN_SOURCE is defined to be 500. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 23:56 Message: Logged In: YES user_id=21627 There is no way to avoid this. Including Python.h may change the contents of header files, e.g. by changing the size of off_t. It is absolutely necessary to have these changes in effect before system headers are included, or else there would be ABI inconsistencies. It is regrettable that vendors require us to implement such requirements to use useful features (e.g. LFS). ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2003-07-07 23:52 Message: Logged In: YES user_id=94539 Requiring #include to be first is a regretable design decision that other software packages regretably also make. It makes interoperability a challenge. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2003-07-07 23:50 Message: Logged In: YES user_id=94539 I set some environment variables that impact the configure run: CC=newcc CXX=newxlC F77=newxlf F90=newxlf90 -qsuffix=f=f90 CPP=gcc -E I am rerunning the test with Python2.3b2. Here is how I am invoking configure. ./configure --prefix=${HOME}/python23b2 --enable-shared --disable-ipv6 ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 23:47 Message: Logged In: YES user_id=21627 This is not a bug in Python, but in your code. Python.h must be the first include file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767374&group_id=5470 From noreply@sourceforge.net Mon Jul 7 23:08:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 15:08:49 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-764188 ] setvbuf for File object Message-ID: Feature Requests item #764188, was opened at 2003-07-01 22:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yue Luo (yueluo) Assigned to: Nobody/Anonymous (nobody) Summary: setvbuf for File object Initial Comment: I wonder if it is possible to add a new method setvbuf to File object. The method does the same as the setvbuf() in stdio.h. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 00:08 Message: Logged In: YES user_id=21627 What buf argument would you like to pass? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 From noreply@sourceforge.net Tue Jul 8 00:14:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 16:14:23 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-764188 ] setvbuf for File object Message-ID: Feature Requests item #764188, was opened at 2003-07-01 20:21 Message generated for change (Comment added) made by yueluo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yue Luo (yueluo) Assigned to: Nobody/Anonymous (nobody) Summary: setvbuf for File object Initial Comment: I wonder if it is possible to add a new method setvbuf to File object. The method does the same as the setvbuf() in stdio.h. ---------------------------------------------------------------------- >Comment By: Yue Luo (yueluo) Date: 2003-07-07 23:14 Message: Logged In: YES user_id=806666 Sorry, I did not make myself clear. I just want to be able to change the buffer size or the buffer mode of a file object. Especially, I often want to change the standard output buffer mode to line buffer so that I can see the result immediately even when the output has been redirected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 22:08 Message: Logged In: YES user_id=21627 What buf argument would you like to pass? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 From noreply@sourceforge.net Tue Jul 8 04:37:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 20:37:10 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-588756 ] python should obey the FHS Message-ID: Feature Requests item #588756, was opened at 2002-07-30 13:12 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588756&group_id=5470 >Category: None >Group: None Status: Open Resolution: None Priority: 3 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: python should obey the FHS Initial Comment: [From: http://bugs.debian.org/134762] FHS Compliance - .py{,c} are architecture independant thus belong in /usr/share The Python manual makes it clear that byte compiled python files are platform independant, and thus belong in arch-independant packages and stored in /usr/share, as per the FHS recommendations for such things. So the request is to store them in /share/pythonX.Y. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-07 20:37 Message: Logged In: YES user_id=357491 I think PYC files can be considered either libraries or data files. Either way I am making this a feature request instead of a bug. ---------------------------------------------------------------------- Comment By: Adrian van den Dries (cantanker) Date: 2003-06-18 16:32 Message: Logged In: YES user_id=209092 Did anyone bother *reading* the FHS? http://www.pathname.com/fhs/2.2/fhs-4.7.html > /usr/lib includes object files, libraries, and internal binaries http://www.pathname.com/fhs/2.2/fhs-4.11.html > The /usr/share hierarchy is for all read-only architecture independent data files. .py{,c} files are *libraries*, not *data files*. Thankyou, move along. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-03 09:38 Message: Logged In: YES user_id=357491 It won't help with that request. Doing that would require changing install paths as suggested below. As for your questions about implementing --fhs-prefix, I can answer a few. For Distutils questions you can just email python-dev to get the attention of Distutils developers. For adding a second site-packages directory I am against (use PYTHONPATH if that is needed). ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2003-06-03 05:49 Message: Logged In: YES user_id=60903 PEP 304 addresses one part: the location of the generated .py[co] files. I fail to see, how it adds support to put .py files in /usr/share. So it partly solves the problem. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-20 21:38 Message: Logged In: YES user_id=357491 Will PEP 304 solve your problem? ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-08-31 01:59 Message: Logged In: YES user_id=60903 Ok, I'll give --fhs-prefix a try. some questions: - the lib_python in getpath.c hardcodes lib/pythonX.Y to search for the libraries. Is it enouogh to set PYTHONPATH to pythonX.Y? - who to ask for distutils? are there concerns if a module/library is splitted over two directories? Or should there symlinks from /usr/lib/pythonX.Y to /usr/share/pythonX.Y? - currently there is only one site-packages directory. how should two site-packages be supported (lib and share)? - speaking of etc: this is a configuration file and should belong into the etc hierarchy. should etc be searched before or after the library directories? Python's include files: not all packages separate platform specific headers from generic headers, probably therefore the FHS puts them in /usr/include. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-08-30 13:51 Message: Logged In: YES user_id=45365 The layouts are similar, but not the same. MacPython-OS9 uses the source tree layout, and Windows-Python too, IIRC. MacPython-OSX in a framework build uses a normal layout, but in a very funny place, with lots of symlinks to make it behave like a framework. I would be very surprised if, say WinCE python or AS/400 python had anything resembling a unix layout. But all these layouts are similar enough that I've never come across a Python where I felt completely lost. I think there's nothing wrong with enabling people to use their preferred layout, if they have a good reason for it, but I would be against enforcing it unless the advantages are clear and universal. And someone has to do the work:-) ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-30 13:32 Message: Logged In: YES user_id=163326 Sorry, Matthias. I was confusing the FHS with the Linux Standard Base. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-30 13:24 Message: Logged In: YES user_id=163326 I assume that the Python directory layout is the same on all currently supported platforms by Python. I really don't know enough to be sure - the less that's true, the less my following argument will be valid: There are really two concerns: 1) make Python conform to the FHS 2) make Python behave the same cross-platform (Windows, Unix, Mac, BeOS, OS/2, VMS, AS/400, ...) You can't have both unless you force the FHS directory layout onto all other platforms. I personally think that 2) is a good thing. I welcome the proposal of a configuration option to make Python FHS-compliant, but I think it should not be the default. Btw. you'd probably have to patch distutils, too. Jack said that Pyhon include files should be cross-platform. AFAIK they are, with one exceptions: pyconfig.h. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-08-30 05:33 Message: Logged In: YES user_id=45365 Well... the usual way in which people implemented sharing between architectures was that the /usr/share hierarchy duplicated the other hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross- platform from an nfs server. That's the architecture the Python install was created for. I have no idea why FHS modified this test-and-tried layout that's been in use for at least 15 years. But: if you really want the other layout, why not submit a fix to configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/ share and if that option is present override the Makefile.pre.in declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR? (Hmm, coming to think of it: it seems rather silly that the FHS puts include files into /usr/include, where they aren't shared... If there's one thing that can be crossplatform it's source code....) ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-08-30 05:33 Message: Logged In: YES user_id=45365 Well... the usual way in which people implemented sharing between architectures was that the /usr/share hierarchy duplicated the other hierarchies (i.e. with bin, lib, etc), and it was simply mounted cross- platform from an nfs server. That's the architecture the Python install was created for. I have no idea why FHS modified this test-and-tried layout that's been in use for at least 15 years. But: if you really want the other layout, why not submit a fix to configure.in and Makefile.pre.in? Simply add, say, --fhs-prefix=/usr/ share and if that option is present override the Makefile.pre.in declarations for SCRIPTDIR, LIBDEST and INCLUDEDIR? (Hmm, coming to think of it: it seems rather silly that the FHS puts include files into /usr/include, where they aren't shared... If there's one thing that can be crossplatform it's source code....) ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-08-30 04:30 Message: Logged In: YES user_id=60903 when configured with --prefix=/usr/share and --exec-prefix=/usr, python installs the header files into /usr/share/include/pythonX.Y, which is at least unusual. According to the FHS these files should go into /usr/include/pythonX.Y ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-08-30 03:52 Message: Logged In: YES user_id=60903 Not yet. --prefix=/foo/share/pythonX.Y would lead to /foo/share/pythonX.Y/lib/pythonX.Y. The SCRIPTDIR is somewhat hardcoded in getpath.c. So it's not possible to install into /foo/share/pythonX.Y, only /foo/share/lib/pythonX.Y is supported. The FHS doesn't specify where to put files inside /usr/share, but most distributions put application specific files directly in /usr/share. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-08-30 01:35 Message: Logged In: YES user_id=45365 I'm confused. If you configure with --exec-prefix=/foo --prefix=/foo/share/pythonX.Y isn't that good enough? If it's good enough (i.e. if it allows you to build a Python that adheres to the FHS if you are so inclined) that I agree with ghaering: there's no reason to force people to adhere to the Filesystem Hierarchy Standard, so let's close the bug. If it is impossible to make an FHS-compliant distribution with the current setup: please explain. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-08-29 23:57 Message: Logged In: YES user_id=60903 The reason given to close the report seems to be invalid. The FHS has nothing to with Debian (except that we follow the FHS). The FHS is targeted at Unix distributions, so it's neither limited to a single distribution nor to Linux distributions in general. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2002-08-25 05:41 Message: Logged In: YES user_id=163326 Python runs on dozens of platforms besides Debian Linux. Thus the Linux FHS shouldn't concern Python at all. I'd propose to close this bug as "Invalid". ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2002-08-03 04:13 Message: Logged In: YES user_id=21627 I think this requires a PEP. A Python package can consist of byte code modules and extension modules; arranging the package loader to find those in different directories is a challenge. ---------------------------------------------------------------------- Comment By: Matthias Klose (doko) Date: 2002-07-30 13:15 Message: Logged In: YES user_id=60903 FHS: Filesystem Hierarchy Standard http://www.pathname.com/fhs/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=588756&group_id=5470 From noreply@sourceforge.net Tue Jul 8 05:11:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 21:11:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-693255 ] 2.3a2 site.py non-existing dirs Message-ID: Bugs item #693255, was opened at 2003-02-25 14:44 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: James P Rutledge (jrut) Assigned to: Just van Rossum (jvr) Summary: 2.3a2 site.py non-existing dirs Initial Comment: In Python 2.3a2 the site.py leaves non-existing directories in sys.path. On my Debian Linux system, using Python 2.3a2, the sys.path, after site.py is executed during interpreter initialization, includes the entry /usr/local/lib/python23.zip although no such directory currently exists on my system. The module documentation contained in site.py does state "Non-existing directories (or non-directories) are never added to sys.path" ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-07 21:11 Message: Logged In: YES user_id=357491 Can someone with more experience with the "official" policy of of site.py say whether or not the docs should be changed or site.py itself? ---------------------------------------------------------------------- Comment By: James P Rutledge (jrut) Date: 2003-05-29 12:20 Message: Logged In: YES user_id=720847 I do not know what policy is desired for the condition of the path after executing site.py. I found the problem when I switched to try 2.3 and used an application I wrote which searches the path to obtain information about installed modules. During troubleshooting, the change in site.py from 2.2 to 2.3, to stop removing non-existent directories in the path, became evident as the reason for the application finding a non-existent directory in the path. The application was, of course, easily changed to skip non-existent directories. The question is whether removing of non-existent directories in the path _should_ be done by site.py ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-28 18:33 Message: Logged In: YES user_id=357491 I take it the docs are what needs to change and not site.py? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-02-26 00:43 Message: Logged In: YES user_id=92689 The docs are indeed wrong. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-25 19:08 Message: Logged In: YES user_id=33168 Just, does the doc still need to be updated? ---------------------------------------------------------------------- Comment By: James P Rutledge (jrut) Date: 2003-02-25 18:56 Message: Logged In: YES user_id=720847 Additional info -- the site.py used in Python 2.2.2 explicitly removes non-existing and non-directory files from sys.path. The Python 2.3 site.py does not have that feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470 From noreply@sourceforge.net Tue Jul 8 05:28:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 21:28:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-544248 ] gcc warning in unicodeobject.c Message-ID: Bugs item #544248, was opened at 2002-04-15 09:29 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=544248&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 1 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: gcc warning in unicodeobject.c Initial Comment: gcc 2.96 on Linux (RedHat 7.1) issues the following warning when compiling Objects/unicodeobject.c 2.138 (configured with --enable-unicode=ucs4) Objects/unicodeobject.c: In function `PyUnicodeUCS4_Format': Objects/unicodeobject.c:5574: warning: int format, long int arg (arg 3) Objects/unicodeobject.c:5574: warning: unsigned int format, long unsigned int arg (arg 4) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-07 21:28 Message: Logged In: YES user_id=357491 Using gcc 3.1 on OS X I don't get any warnings. Anyone still getting warnings? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-06-19 10:25 Message: Logged In: YES user_id=31392 Any chance of progress here? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-18 12:22 Message: Logged In: YES user_id=89016 If all relevant implementations of sprintf() support %lx I'd say we should change PyString_FromFormatV(). But to decide that, you should definitely ask on Python-dev. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-13 06:47 Message: Logged In: YES user_id=33168 Line is 6469 in current CVS. I fixed the warning for arg 3, arg 4 is a bit harder. It requires using %lx which is not supported in PyString_FromFormatV(). I'm not sure the changes are worthwhile (that's why I didn't make the change). To fix PyString_FromFormatV(), these changes are required: Line 194: - if (*f == 'l' && *(f+1) == 'd') + if (*f == 'l' && (*(f+1) == 'd' || *(f+1) == 'x')) Line: 266 - if (*f == 'l' && *(f+1) == 'd') { + if (*f == 'l' && (*(f+1) == 'd' || *(f+1) == 'x')) { Line: 287 - sprintf(s, "%x", va_arg(vargs, int)); + if (longflag) + sprintf(s, "%lx", va_arg(vargs, unsigned long)); + else + sprintf(s, "%x", va_arg(vargs, unsigned) ); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=544248&group_id=5470 From noreply@sourceforge.net Tue Jul 8 05:35:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 21:35:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 22:32 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 7 Submitted By: Kurt Grittner (grittkmg) Assigned to: Mark Hammond (mhammond) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-07-08 14:35 Message: Logged In: YES user_id=14198 I also can't repro this, but do believe it. I think the patch is simple: RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.268 diff -r1.268 socketmodule.c 3292c3292 < atexit(os_cleanup); --- > Py_AtExit(os_cleanup); This will cause the cleanup function to be called during Py_Finalize(), which is never implicitly called in a DllMain. Can you let me know if this fixes it? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-08 04:05 Message: Logged In: YES user_id=816888 From: "Eugene Gershnik [SDK MVP]" References: <6hvigvgnlsqhihobl06jt1edjfsv7r4pja@4ax.com> Subject: Re: WSAStartup and WSACleanup from within a DLL Date: Mon, 7 Jul 2003 10:26:25 -0700 Lines: 24 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Newsgroups: microsoft.public.win32.programmer.networks NNTP-Posting-Host: dsl093-033-235.snd1.dsl.speakeasy.net 66.93.33.235 Path: TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl Xref: TK2MSFTNGP08.phx.gbl microsoft.public.win32. programmer.networks:43932 It is in general a bad idea. atexit() handlers are running from within DLL_PROCESS_DETACH notification and this is a bad place to clean up other DLLs. See remarks to DllMain in MSDN for details. Note that it is also a bad idea to use C++ global or static objects to startup/cleanup winsock since those als rely on atexit() for destruction. The best way to init winsock for your DLL is to have something like MyDllInit() and MyDllTerm() functions that should be called be the user of the DLL. Eugene Kurt Grittner wrote: > Hello Group, > > If you call all of your socket functions from within a DLL, and you > do the WSAStartup() inside the DLL, is it legal to then have your > WSACleanup() run via atexit(StaticFunctionInDLL)? I am getting > weird behavior (GPF) on someone else's program when they do this. > The WSACleanup ends up getting called from crt0dat. Any Opinions? > > Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 19:34 Message: Logged In: YES user_id=816888 Here is a small windows project that causes the error for me on my faster machines. I will try it on a bunch of other machines. badsock good Runs it the good way badsock bad or just plain badsock Causes the error for me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 16:13 Message: Logged In: YES user_id=816888 Well, Python is new to me, but Win32 isn't. My theory for why it fails is simply that the program breaks the rules and creates a window for failure. On my system the window is large. On yours, the window is smaller. This is a machine with lots of memory. (AMD XP2000, 512MB RAM). It has a new hard drive with an on board 8MB cache. Things happen fast on this machine. This single fact could explain why the failure condition always wins the race for me. The machines at work (which also fail) are similar. Who puts win98SE on a brand new machine these days? Hmmm... maybe not too many people. I can turn your argument around... I have dozens of network programs running on this machine, many of which I wrote, none of which play fast-and-loose with threaded-DLL's, all of which work. Python is the only network program that fails. It fails every single time. I luckily have access to the source, so I can find the bug and fix it. Great! The wonders of open source. Well, anyhow, I was only trying to lend a hand. Python looks promising. I am looking at it as a potential replacement for VB/ActiveX. I am going to try this on some older, slower machines. Also, I will attempt to code a demo program that reproduces the bad behavior by duplicating the steps taken in the socketmodule, and hopefully also duplicating the error on more machines. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-07 14:26 Message: Logged In: YES user_id=31435 Mark, can you take a look at this? If you agree the design is hosed, it would be good to fix it before 2.3r1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-07 14:21 Message: Logged In: YES user_id=31435 You're trying too hard . I'm not arguing about the design (for one thing, it's not my design, and I don't know anything about it), I'm wondering both why I can't reproduce a problem, and especially why no other report of this has ever been made. You surely don't believe you're the only programmer to try sockets in Python on Windows, right? I also tried it under an up-to-date Win98SE, also with MSVC 6 and all current IE 6 patches. Indeed, that's the machine I've built the PythonLabs Windows installer *on* for the last two years. No problem. Everyone who has ever run the Python test suite on Windows has exercised sockets on Windows, and so has anyone who has ever run Zope on Windows, etc. It may indeed be a bit of Rocket Science if you don't have a theory for why it fails only when you run it! The reason I'm keen to know is that only someone who can see the problem can test a putative fix (and so confirm-- or refute --that the problem goes away). ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 14:00 Message: Logged In: YES user_id=816888 Umm, this is not rocket science. WSACleanup() is being called in the wrong context. Startup is called in a DLL context. That puts the info in Thread Local Storage (TLS). The DLL Is allowed to unload with an atexit() pointer still pending to it. This is bad design. You should always call startup/cleanup in pairs and in the same thread context. As I said before this happens on every win98SE machine that I have tried it on. I have no firewall or virus scanner. This is a fairly recent installation of win98 with all of the MS updates for I.E. Apart from that, the most unusual thing is the presence of the VisualStudio 6.0 suite of programs. I can do a new install of win98SE on an old machine, just out of curiosity, but you only have to read this web site to see that this design for startup/cleanup calls is a recipie for disaster: http://support.microsoft.com/default.aspx?scid=http: //support.microsoft.com:80/support/kb/articles/Q237/5/72. ASP&NoWebContent=1 Here is a list of some of the modules running on my machine: USER32.DLL 4.10.2227 Microsoft Corporation Win32 USER32 core component C:\WINDOWS\SYSTEM\USER32. DLL 4/21/00 3:33:18 PM GMT Microsoft(R) Windows(R) Operating System bfc00000 - bfc11000 GDI32.DLL 4.10.1998 Microsoft Corporation Win32 GDI core component C:\WINDOWS\SYSTEM\GDI32. DLL 4/23/98 4:24:18 AM GMT Microsoft(R) Windows(R) Operating System bff20000 - bff46000 ADVAPI32.DLL 4.80.1675 Microsoft Corporation Win32 ADVAPI32 core component C: \WINDOWS\SYSTEM\ADVAPI32.DLL 4/23/99 4:37:33 PM GMT Microsoft(R) Windows(R) Operating System bfe80000 - bfe90000 KERNEL32.DLL 4.10.2222 Microsoft Corporation Win32 Kernel core component C: \WINDOWS\SYSTEM\KERNEL32.DLL 4/23/99 12:45:39 AM GMT Microsoft(R) Windows(R) Operating System bff70000 - bffe3000 MPR.DLL 4.10.1998 Microsoft Corporation WIN32 Network Interface DLL C:\WINDOWS\SYSTEM\MPR. DLL 4/23/99 4:37:36 PM GMT Microsoft(R) Windows(R) Operating System 7fbf0000 - 7fbfe000 MSNP32.DLL 4.10.2222 Microsoft Corporation Network provider for Microsoft networks C:\WINDOWS\SYSTEM\MSNP32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fb20000 - 7fb34000 MSNET32.DLL 4.10.2224 Microsoft Corporation Microsoft 32-bit Network API Library C: \WINDOWS\SYSTEM\MSNET32.DLL 11/12/99 4:15:15 AM GMT Microsoft(R) Windows(R) Operating System 7f300000 - 7f313000 MPREXE.EXE 4.10.1998 Microsoft Corporation WIN32 Network Interface Service Process C:\WINDOWS\SYSTEM\MPREXE.EXE 4/23/98 2:19:38 AM GMT Microsoft(R) Windows(R) Operating System 00500000 - 00507000 MPRSERV.DLL 4.10.2222 Microsoft Corporation Multinet Router C: \WINDOWS\SYSTEM\MPRSERV.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fad0000 - 7faf6000 NETAPI32.DLL 4.10.1998 Microsoft Corporation 32-bit network API DLL C: \WINDOWS\SYSTEM\NETAPI32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7f990000 - 7f995000 NETBIOS.DLL C:\WINDOWS\SYSTEM\NETBIOS. DLL 4/23/99 4:37:39 PM GMT 7f840000 - 7f848000 RNR20.DLL 4.10.2222 Microsoft Corporation Windows Socket2 NameSpace DLL C: \WINDOWS\SYSTEM\RNR20.DLL 4/23/99 4:38:44 PM GMT Microsoft(R) Windows(R) Operating System 783c0000 - 783cf000 MSAFD.DLL 4.10.1998 Microsoft Corporation Microsoft Windows Sockets 2.0 Service Provider C:\WINDOWS\SYSTEM\MSAFD.DLL 4/23/99 4: 38:11 PM GMT Microsoft(R) Windows(R) Operating System 7b410000 - 7b41b000 RPCLTSCM.DLL 4.71.2900 Microsoft Corporation Remote Process Control LTSCM DLL C: \WINDOWS\SYSTEM\RPCLTSCM.DLL 4/23/99 4:38:45 PM GMT Microsoft® Windows® Operating System 78320000 - 7832a000 WSOCK32.DLL 4.10.1998 Microsoft Corporation BSD Socket API for Windows C: \WINDOWS\SYSTEM\WSOCK32.DLL 4/23/99 4:39:14 PM GMT Microsoft(R) Windows(R) Operating System 75fa0000 - 75faa000 MSWSOCK.DLL 4.10.2222 Microsoft Corporation Microsoft WinSock Extension APIs C: \WINDOWS\SYSTEM\MSWSOCK.DLL 4/23/99 4:38:30 PM GMT Microsoft(R) Windows(R) Operating System 794d0000 - 794e5000 WS2_32.DLL 4.10.2222 Microsoft Corporation Windows Socket 2.0 32-Bit DLL C: \WINDOWS\SYSTEM\WS2_32.DLL 4/23/99 4:39:13 PM GMT Microsoft(R) Windows(R) Operating System 76000000 - 76012000 WS2HELP.DLL 4.10.1998 Microsoft Corporation Windows Socket 2.0 Helper for Windows 98 C:\WINDOWS\SYSTEM\WS2HELP.DLL 4/23/99 4: 39:13 PM GMT Microsoft(R) Windows(R) Operating System 75fe0000 - 75fe6000 DIGEST.DLL 6.00.2800.1106 Microsoft Corporation Digest SSPI Authentication Package C: \WINDOWS\SYSTEM\DIGEST.DLL 8/29/02 11:21:08 AM GMT Microsoft® Windows® Operating System 007a0000 - 007b0000 MSNSSPC.DLL 6.00.7753 Microsoft Corporation MSN Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSNSSPC.DLL 4/23/99 4:38:21 PM GMT Microsoft® Internet Services 7a210000 - 7a22f000 MSAPSSPC.DLL 5.00.7729 Microsoft Corporation DPA Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSAPSSPC.DLL 4/23/99 4:38:11 PM GMT Microsoft® Internet Services 7b3f0000 - 7b401000 MSVCRT40.DLL 4.22.0000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT40.DLL 4/23/99 4:38:29 PM GMT Microsoft® Visual C++ 79660000 - 796b5000 SECUR32.DLL 4.10.2222 Microsoft Corporation Microsoft Win32 Security Services C: \WINDOWS\SYSTEM\SECUR32.DLL 4/23/99 4:37:39 PM GMT Microsoft(R) Windows(R) Operating System 7f870000 - 7f87a000 RPCSS.EXE 4.71.2900 Microsoft Corporation Distributed COM Services C: \WINDOWS\SYSTEM\RPCSS.EXE 9/1/98 6:18:39 PM GMT Microsoft(R) Windows NT(TM) Operating System 01000000 - 01005000 MSVCRT20.DLL 2.11.000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT20.DLL 4/23/99 4:37:36 PM GMT Microsoft® Visual C++ 7fc30000 - 7fc75000 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-07 13:13 Message: Logged In: YES user_id=31435 Kurt, which versions of Windows and winsock.dll are you using? I continue to be unable to reproduce any problem here, and there have been no other reports of this despite thousands of Python programs using sockets on Windows for a decade. I have to conclude there's something unique in your setup. FYI, sometimes virus scanners and/or "personal firewalls" cause bizarre crashes during startup or shutdown. Are you running one (or more) of those? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 11:29 Message: Logged In: YES user_id=816888 I have a working fix for this problem, but the code is a fairly ugly hack. (A terrible thing to do to such a well organized codebase). 1. I exported a fini_socket() function from the PYD DLL. 2. I cloned the dynamic lookup function to check for the optional fini_socket() name as well as the init_socket(). If found, I remember it in a global. 3. In PyImport_Cleanup() I call the fini_socket() routine (if present) before these modules start getting freed. 4. In NTInit() I add to a counter instead of using atexit() 5. fini_socket() calls NTcleanup(), which simply calls WSACleanup 'counter' times to release the winsock DLL. This works, so now I can go on with my Python study. If anyone wants my hack code, just email me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 06:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 04:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-07 02:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Tue Jul 8 05:39:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 21:39:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-743692 ] test_socketserver: Fatal error: Invalid thread state Message-ID: Bugs item #743692, was opened at 2003-05-27 00:30 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743692&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Mark Hammond (mhammond) Summary: test_socketserver: Fatal error: Invalid thread state Initial Comment: Mark, I believe this started happening on Solaris 8 (only AFAIK) after some of your thread changes. Do you have access to a Solaris 8 box? I can try to debug if you give me some ideas. This is happening on the snake farm. Actually, we have a Sol8 box here. I can try to fire it up and see if the problem exists on that box. If so, I can give you access. When running test_socketserver, some way through the test there's the fatal error. Fatal Python error: Invalid thread state for this thread Let me know what more info I can provide. Sorry, short on ideas/time, just wanted to get this documented. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-07-08 14:39 Message: Logged In: YES user_id=14198 I don't have access to a sol8 box, nor would I really know what to do when I got there :) Any chance of a stack-trace? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743692&group_id=5470 From noreply@sourceforge.net Tue Jul 8 06:21:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 22:21:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-767563 ] [win32] some .dsp files have unix line endings Message-ID: Bugs item #767563, was opened at 2003-07-08 17: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=767563&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Evans (tim_evans) Assigned to: Nobody/Anonymous (nobody) Summary: [win32] some .dsp files have unix line endings Initial Comment: Some of the .dsp (DevStudio Project) files in the source .tgz for Python 2.3b2 have unix line endings instead of dos. "_csv.dsp" is one such file. This causes DevStudio to fail to load them correctly, and prevents those modules from beign built. Running unix2dos the .dsp files fixed the problem. I may have noticed this where others didn't because I unpacked the .tgz on a linux file server and then compiled on a WinXP client. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767563&group_id=5470 From noreply@sourceforge.net Tue Jul 8 06:43:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 22:43:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-715063 ] bsddb.first()/next() raise undocumented exception Message-ID: Bugs item #715063, was opened at 2003-04-03 20:03 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Open Resolution: Works For Me Priority: 5 Submitted By: Christian Stork (cst) Assigned to: Gregory P. Smith (greg) Summary: bsddb.first()/next() raise undocumented exception Initial Comment: bsddb object's first() & next() methods raise an undocumented exception. Wouldn't returning None make much more sense? And shouldn't this be documented? Python 2.3a2+ (#2, Mar 21 2003, 22:13:05) [GCC 3.2.3 20030316 (Debian prerelease)] on linux2 >>> import bsddb >>> h.bsddb.hashopen("testdb") >>> h.first() ------------------------------------------------------------ Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/bsddb/__init__.py", line 134, in first rv = self.dbc.first() DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/ data pair found') Note: The same exception appeared for the equivalent dbhash methods. But I assume this should be fixed if this bug is fixed. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-07-07 22:43 Message: Logged In: YES user_id=413 hehe. good point. you can tell i haven't written pybsddb cursor code in a while, its api is not fresh in my mind. ... * greg puts on pybsddb hat I notice that my dbtables.py uses set_range such that it expects it to raise an exception, not return None. That means there are surely others out there whos code that change would break as well. How about I change the default to be consistent by having DBCursor set* methods returns None and add a set_cursor_set_returns_none() method to enable the behaviour anyone finds most convenient for their situation. Or does anyone think the default behaviour should not change? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-07 12:39 Message: Logged In: YES user_id=12800 Greg, correct me if I'm wrong but cursor.next() already has the return value issue you point out, i.e. it can return None or a tuple. My pattern has been to do stuff like this: rec = c.first() while rec: key, val = rec rec = c.next() so it doesn't bother me too much if the cursor.set() method works the same way . I think the documentation of set_get_returns_none is correct and cursor.set() should be changed to follow those rules. I'm not too concerned with backward compatibility either because this is the common .set() idiom I use: try: rec = c.set('somekey') except db.DBNotFoundError: rec = None while rec: ... This code would not break by changing .set(), but I would be able to remove the try/except. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-07 11:56 Message: Logged In: YES user_id=413 Looking in the code, no, none of the DBCursor set* methods follow set_get_returns_none() to not raise an exception. The documentation for set_get_returns_none implies that they should as they're all cursor "get" methods. All of the set methods normally return tuples of (key, data) rather than a single value. If we modify them to return None rather than raise a DBNotFoundError it makes for an annoying interface because it wouldn't always return a tuple. I'm inclined to leave the set methods as they are and fix the set_get_returns_none() documentation unless someone can come up with good examples why it should be different. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-07 10:49 Message: Logged In: YES user_id=12800 Greg, what about cursor.set() -- I don't think this follows set_get_returns_none() does it? I wonder if it should. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 17:01 Message: Logged In: YES user_id=413 DBNotFoundError derives from KeyError. The old bsddb library also raised KeyError on first/last/next calls when there was no more data rather than returning None so that interface cannot be changed. (I agree, returning None would make more sense; but I can't break the old interface). The new pybsddb interface's DB and DBEnv set_get_returns_none method does allow you to control this behaviour. If you are using the old style bsddb interface then you do not have access to the DBEnv before the DB object is created (DB objects inherit the flag setting from the DBEnv when they are created) so you'll need to call set_get_returns_none on the DB object itself: import bsddb # python 2.3 bsddb (aka bsddb3 or pybsddb) hdb = bsddb.hashopen("myhash", 'c') hdb.db.set_get_returns_none(1) # will only work on python 2.3 / pybsddb spam = hdb.first() while spam: spam = hdb.next() # notice there were no errors. I've looked at the code for first/last/prev/get and they all use the same internal DBCursor_get wrapper that obeys the set_get_returns_none flag so that you can write simple "foo = hdb.first(); while not foo: foo = hdb.next()" code. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 16:24 Message: Logged In: YES user_id=413 i'm taking a look. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-07 15:46 Message: Logged In: YES user_id=12800 pybsddb has this option to return None from cursor.get() methods instead of raising DBNotFoundError. The DBEnv method set_get_returns_none() can be used to change the behavior, although the default is to return None. I agree that this is very handy! I suppose .first() and .last() should perhaps honor this config as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 From noreply@sourceforge.net Tue Jul 8 06:46:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 22:46:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-766891 ] oct() function does not represent zero correctly Message-ID: Bugs item #766891, was opened at 2003-07-06 19:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766891&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Joshua Biagio (roehnan) Assigned to: Nobody/Anonymous (nobody) Summary: oct() function does not represent zero correctly Initial Comment: Under python 2.3b2, the oct() function does not return '00' for 0 as the grammar specifies, but simply '0'. I believe this to be a bug because the hex() function returns '0x0' for zero. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-08 00:46 Message: Logged In: YES user_id=80475 The grammar does specify "0" followed by one or more octdigits; however, that serves only to tell the interpreter how to convert a string into an internal representation. Since "00" and "0" unambiguously convert to zero, there is no harm with the current situation. On the contrary, attempts to "repair" this one may hurt existing programs relying on the current behavior. I recommend marking this one as Won't Fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766891&group_id=5470 From noreply@sourceforge.net Tue Jul 8 07:11:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 23:11:00 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-683910 ] zipfile should have a tarfile-like API Message-ID: Feature Requests item #683910, was opened at 2003-02-11 00:26 Message generated for change (Settings changed) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=683910&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: zipfile should have a tarfile-like API Initial Comment: zipfile.ZipFile() should have an interface similar to tarfile.TarFile() for extracting files. At it's simplest, this can be written: tf = tarfile.open(self.filename, 'r') for member in tf.getmembers(): tf.extract(member) This does "all the right things". This is a much more pleasant interface to use than the ZipFile equivalent. Assigning to self as a reminder to do this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=683910&group_id=5470 From noreply@sourceforge.net Tue Jul 8 07:15:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 23:15:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-766541 ] string.title() doesn't understand apostrophes Message-ID: Bugs item #766541, was opened at 2003-07-05 19:17 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766541&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steve Greenland (vmole) Assigned to: Nobody/Anonymous (nobody) Summary: string.title() doesn't understand apostrophes Initial Comment: Consider the following: steveg@speedy:~/jbox$ python Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "I've fallen and i can't get up".title() "I'Ve Fallen And I Can'T Get Up" >>> That looks fairly non-standard to me. Apparently, the title() method treats apostrophes as whitespace/word seperators/something. Thanks, Steve ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-08 01:15 Message: Logged In: YES user_id=80475 The determination of what actually constitutes a word is language-dependent. For instance, in French, l'arbre is considered two words. See: http://www.unicode.org/reports/tr21/tr21-5d3.html Also, I tried the VB and MS-Excel implementations (they call it "proper" instead of "title") and they match the current Python behavior. I found no equivalent string method in Java. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-07-06 10:53 Message: Logged In: YES user_id=593130 If the ' directly follows a letter, then it is being used for a contraction and not for indirect speech, and the following letter should not be uppercased. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-06 04:32 Message: Logged In: YES user_id=21627 Unfortunately, this usage of the apostrophe is specific to the English language. Martin says, 'if the apostrophe is used for indirect speech, upper-casing after it is correct'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766541&group_id=5470 From noreply@sourceforge.net Tue Jul 8 07:32:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 23:32:00 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-668905 ] logging module documentation Message-ID: Feature Requests item #668905, was opened at 2003-01-16 16:07 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470 Category: Documentation Group: None >Status: Open >Resolution: Accepted Priority: 5 Submitted By: Richard Jones (richard) >Assigned to: Anthony Baxter (anthonybaxter) Summary: logging module documentation Initial Comment: I believe the logging module documentation needs to give an example of how to simply log to a file. The following example snippet could be appropriate: import logging logger = logging.getLogger('myapp') hdlr = FileHandler('/var/myapp/debug.log') hdlr.setFormatter(Formatter('%(asctime)s %(level)s %(message)s')) logger.addHandler(hdlr) logger.setLevel(DEBUG) ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-08 16:32 Message: Logged In: YES user_id=29957 Why was this closed? nnorwitz's doc fixes, as seen in CVS or http://www.python.org/dev/doc/devel/lib/module-logging.html have no examples section. Running the current logging module docs past a number of python coders here produced a consistent "what the heck?" response - the opening introduction provides no indications of how to use the package. This is a problem for me, right now, so I'm re-opening and assigning to myself to fix. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 16:37 Message: Logged In: YES user_id=80475 Reviewed. Closing RFE. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-26 08:36 Message: Logged In: YES user_id=33168 I just updated the logging documentation. Could you please review for accuracy and completeness? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470 From noreply@sourceforge.net Tue Jul 8 07:57:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 23:57:26 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-764188 ] setvbuf for File object Message-ID: Feature Requests item #764188, was opened at 2003-07-01 22:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yue Luo (yueluo) Assigned to: Nobody/Anonymous (nobody) Summary: setvbuf for File object Initial Comment: I wonder if it is possible to add a new method setvbuf to File object. The method does the same as the setvbuf() in stdio.h. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 08:57 Message: Logged In: YES user_id=21627 I see. Can you explain why invoking "python -u" is insufficient? ---------------------------------------------------------------------- Comment By: Yue Luo (yueluo) Date: 2003-07-08 01:14 Message: Logged In: YES user_id=806666 Sorry, I did not make myself clear. I just want to be able to change the buffer size or the buffer mode of a file object. Especially, I often want to change the standard output buffer mode to line buffer so that I can see the result immediately even when the output has been redirected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 00:08 Message: Logged In: YES user_id=21627 What buf argument would you like to pass? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 From noreply@sourceforge.net Tue Jul 8 07:59:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 07 Jul 2003 23:59:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-766541 ] string.title() doesn't understand apostrophes Message-ID: Bugs item #766541, was opened at 2003-07-06 02:17 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766541&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Steve Greenland (vmole) Assigned to: Nobody/Anonymous (nobody) Summary: string.title() doesn't understand apostrophes Initial Comment: Consider the following: steveg@speedy:~/jbox$ python Python 2.2.3 (#1, Jun 4 2003, 02:54:59) [GCC 3.3 (Debian)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> "I've fallen and i can't get up".title() "I'Ve Fallen And I Can'T Get Up" >>> That looks fairly non-standard to me. Apparently, the title() method treats apostrophes as whitespace/word seperators/something. Thanks, Steve ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 08:59 Message: Logged In: YES user_id=21627 Thanks, Raymond, for this investigation. Closing it as wont-fix - if you want an algorithm that follows the English language rules, you have to implement that yourself. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-08 08:15 Message: Logged In: YES user_id=80475 The determination of what actually constitutes a word is language-dependent. For instance, in French, l'arbre is considered two words. See: http://www.unicode.org/reports/tr21/tr21-5d3.html Also, I tried the VB and MS-Excel implementations (they call it "proper" instead of "title") and they match the current Python behavior. I found no equivalent string method in Java. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-07-06 17:53 Message: Logged In: YES user_id=593130 If the ' directly follows a letter, then it is being used for a contraction and not for indirect speech, and the following letter should not be uppercased. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-06 11:32 Message: Logged In: YES user_id=21627 Unfortunately, this usage of the apostrophe is specific to the English language. Martin says, 'if the apostrophe is used for indirect speech, upper-casing after it is correct'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766541&group_id=5470 From noreply@sourceforge.net Tue Jul 8 08:40:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 00:40:18 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-767592 ] unittest docs don't suggest "unittest.main()" Message-ID: Feature Requests item #767592, was opened at 2003-07-08 17:40 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=767592&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Nobody/Anonymous (nobody) Summary: unittest docs don't suggest "unittest.main()" Initial Comment: By far the most common use of the unittest module I've seen is simply: 1. Define one or more classes that subclass unittest.TestCase. Give them methods that are named "test_foo". 2. Put "if __name__ == '__main__': unittest.main()" at the bottom of the module. Nowhere do the unittest standard library docs make it clear this is the easiest, and most common, way to use the unittest module. The "Organizing test code" section completely fails to mention this, even though I think this should be the first thing described. Instead, it helpfully lists all sorts of ways to use test suites that you rarely, if ever, need in practice. Mention of unittest.main() is buried several sections later, and is very brief. I suggest opening "Organizing test code" with a complete working example demonstrating typical use, e.g.: --- import unittest class TestArithmetic(unittest.TestCase): def test_addition(self): self.failUnlessEqual(1+2, 3) if __name__ == '__main__': unittest.main() --- It's a trivial example, but it could work wonders. I usually recommend the diveintopython.org docs on unittest (http://diveintopython.org/roman_divein.html) due to the state of the official unittest docs. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=767592&group_id=5470 From noreply@sourceforge.net Tue Jul 8 10:42:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 02:42:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-767645 ] incorrect os.path.supports_unicode_filenames Message-ID: Bugs item #767645, was opened at 2003-07-08 11: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=767645&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect os.path.supports_unicode_filenames Initial Comment: At least on OSX, unicode file names are pretty much fully supported, yet os.path.supports_unicode_filenames is False (it comes from posixpath.py, which hard codes it). What would be a proper way to detect unicode filename support for posix platforms? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 From noreply@sourceforge.net Tue Jul 8 12:23:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 04:23:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 07:32 Message generated for change (Comment added) made by grittkmg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 7 Submitted By: Kurt Grittner (grittkmg) Assigned to: Mark Hammond (mhammond) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Kurt Grittner (grittkmg) Date: 2003-07-08 06:23 Message: Logged In: YES user_id=816888 Yes! Changing: atexit(NTcleanup); to: Py_AtExit(NTcleanup); Fixes my nasty GPF! Thanks! By the way, the bad behavior isn't limited to GPF's. On every machine that I tested the echo server received a 'connection reset by peer' error instead of the orderly close that running WSACleanup() from the DLL context provides. I missed the presence of Py_AtExit()... much cleaner than my nasty hack. This is a really cool program. My compliments to the chefs. Kurt ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-07 23:35 Message: Logged In: YES user_id=14198 I also can't repro this, but do believe it. I think the patch is simple: RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.268 diff -r1.268 socketmodule.c 3292c3292 < atexit(os_cleanup); --- > Py_AtExit(os_cleanup); This will cause the cleanup function to be called during Py_Finalize(), which is never implicitly called in a DllMain. Can you let me know if this fixes it? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 13:05 Message: Logged In: YES user_id=816888 From: "Eugene Gershnik [SDK MVP]" References: <6hvigvgnlsqhihobl06jt1edjfsv7r4pja@4ax.com> Subject: Re: WSAStartup and WSACleanup from within a DLL Date: Mon, 7 Jul 2003 10:26:25 -0700 Lines: 24 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Newsgroups: microsoft.public.win32.programmer.networks NNTP-Posting-Host: dsl093-033-235.snd1.dsl.speakeasy.net 66.93.33.235 Path: TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl Xref: TK2MSFTNGP08.phx.gbl microsoft.public.win32. programmer.networks:43932 It is in general a bad idea. atexit() handlers are running from within DLL_PROCESS_DETACH notification and this is a bad place to clean up other DLLs. See remarks to DllMain in MSDN for details. Note that it is also a bad idea to use C++ global or static objects to startup/cleanup winsock since those als rely on atexit() for destruction. The best way to init winsock for your DLL is to have something like MyDllInit() and MyDllTerm() functions that should be called be the user of the DLL. Eugene Kurt Grittner wrote: > Hello Group, > > If you call all of your socket functions from within a DLL, and you > do the WSAStartup() inside the DLL, is it legal to then have your > WSACleanup() run via atexit(StaticFunctionInDLL)? I am getting > weird behavior (GPF) on someone else's program when they do this. > The WSACleanup ends up getting called from crt0dat. Any Opinions? > > Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 04:34 Message: Logged In: YES user_id=816888 Here is a small windows project that causes the error for me on my faster machines. I will try it on a bunch of other machines. badsock good Runs it the good way badsock bad or just plain badsock Causes the error for me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 01:13 Message: Logged In: YES user_id=816888 Well, Python is new to me, but Win32 isn't. My theory for why it fails is simply that the program breaks the rules and creates a window for failure. On my system the window is large. On yours, the window is smaller. This is a machine with lots of memory. (AMD XP2000, 512MB RAM). It has a new hard drive with an on board 8MB cache. Things happen fast on this machine. This single fact could explain why the failure condition always wins the race for me. The machines at work (which also fail) are similar. Who puts win98SE on a brand new machine these days? Hmmm... maybe not too many people. I can turn your argument around... I have dozens of network programs running on this machine, many of which I wrote, none of which play fast-and-loose with threaded-DLL's, all of which work. Python is the only network program that fails. It fails every single time. I luckily have access to the source, so I can find the bug and fix it. Great! The wonders of open source. Well, anyhow, I was only trying to lend a hand. Python looks promising. I am looking at it as a potential replacement for VB/ActiveX. I am going to try this on some older, slower machines. Also, I will attempt to code a demo program that reproduces the bad behavior by duplicating the steps taken in the socketmodule, and hopefully also duplicating the error on more machines. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 23:26 Message: Logged In: YES user_id=31435 Mark, can you take a look at this? If you agree the design is hosed, it would be good to fix it before 2.3r1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 23:21 Message: Logged In: YES user_id=31435 You're trying too hard . I'm not arguing about the design (for one thing, it's not my design, and I don't know anything about it), I'm wondering both why I can't reproduce a problem, and especially why no other report of this has ever been made. You surely don't believe you're the only programmer to try sockets in Python on Windows, right? I also tried it under an up-to-date Win98SE, also with MSVC 6 and all current IE 6 patches. Indeed, that's the machine I've built the PythonLabs Windows installer *on* for the last two years. No problem. Everyone who has ever run the Python test suite on Windows has exercised sockets on Windows, and so has anyone who has ever run Zope on Windows, etc. It may indeed be a bit of Rocket Science if you don't have a theory for why it fails only when you run it! The reason I'm keen to know is that only someone who can see the problem can test a putative fix (and so confirm-- or refute --that the problem goes away). ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 23:00 Message: Logged In: YES user_id=816888 Umm, this is not rocket science. WSACleanup() is being called in the wrong context. Startup is called in a DLL context. That puts the info in Thread Local Storage (TLS). The DLL Is allowed to unload with an atexit() pointer still pending to it. This is bad design. You should always call startup/cleanup in pairs and in the same thread context. As I said before this happens on every win98SE machine that I have tried it on. I have no firewall or virus scanner. This is a fairly recent installation of win98 with all of the MS updates for I.E. Apart from that, the most unusual thing is the presence of the VisualStudio 6.0 suite of programs. I can do a new install of win98SE on an old machine, just out of curiosity, but you only have to read this web site to see that this design for startup/cleanup calls is a recipie for disaster: http://support.microsoft.com/default.aspx?scid=http: //support.microsoft.com:80/support/kb/articles/Q237/5/72. ASP&NoWebContent=1 Here is a list of some of the modules running on my machine: USER32.DLL 4.10.2227 Microsoft Corporation Win32 USER32 core component C:\WINDOWS\SYSTEM\USER32. DLL 4/21/00 3:33:18 PM GMT Microsoft(R) Windows(R) Operating System bfc00000 - bfc11000 GDI32.DLL 4.10.1998 Microsoft Corporation Win32 GDI core component C:\WINDOWS\SYSTEM\GDI32. DLL 4/23/98 4:24:18 AM GMT Microsoft(R) Windows(R) Operating System bff20000 - bff46000 ADVAPI32.DLL 4.80.1675 Microsoft Corporation Win32 ADVAPI32 core component C: \WINDOWS\SYSTEM\ADVAPI32.DLL 4/23/99 4:37:33 PM GMT Microsoft(R) Windows(R) Operating System bfe80000 - bfe90000 KERNEL32.DLL 4.10.2222 Microsoft Corporation Win32 Kernel core component C: \WINDOWS\SYSTEM\KERNEL32.DLL 4/23/99 12:45:39 AM GMT Microsoft(R) Windows(R) Operating System bff70000 - bffe3000 MPR.DLL 4.10.1998 Microsoft Corporation WIN32 Network Interface DLL C:\WINDOWS\SYSTEM\MPR. DLL 4/23/99 4:37:36 PM GMT Microsoft(R) Windows(R) Operating System 7fbf0000 - 7fbfe000 MSNP32.DLL 4.10.2222 Microsoft Corporation Network provider for Microsoft networks C:\WINDOWS\SYSTEM\MSNP32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fb20000 - 7fb34000 MSNET32.DLL 4.10.2224 Microsoft Corporation Microsoft 32-bit Network API Library C: \WINDOWS\SYSTEM\MSNET32.DLL 11/12/99 4:15:15 AM GMT Microsoft(R) Windows(R) Operating System 7f300000 - 7f313000 MPREXE.EXE 4.10.1998 Microsoft Corporation WIN32 Network Interface Service Process C:\WINDOWS\SYSTEM\MPREXE.EXE 4/23/98 2:19:38 AM GMT Microsoft(R) Windows(R) Operating System 00500000 - 00507000 MPRSERV.DLL 4.10.2222 Microsoft Corporation Multinet Router C: \WINDOWS\SYSTEM\MPRSERV.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fad0000 - 7faf6000 NETAPI32.DLL 4.10.1998 Microsoft Corporation 32-bit network API DLL C: \WINDOWS\SYSTEM\NETAPI32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7f990000 - 7f995000 NETBIOS.DLL C:\WINDOWS\SYSTEM\NETBIOS. DLL 4/23/99 4:37:39 PM GMT 7f840000 - 7f848000 RNR20.DLL 4.10.2222 Microsoft Corporation Windows Socket2 NameSpace DLL C: \WINDOWS\SYSTEM\RNR20.DLL 4/23/99 4:38:44 PM GMT Microsoft(R) Windows(R) Operating System 783c0000 - 783cf000 MSAFD.DLL 4.10.1998 Microsoft Corporation Microsoft Windows Sockets 2.0 Service Provider C:\WINDOWS\SYSTEM\MSAFD.DLL 4/23/99 4: 38:11 PM GMT Microsoft(R) Windows(R) Operating System 7b410000 - 7b41b000 RPCLTSCM.DLL 4.71.2900 Microsoft Corporation Remote Process Control LTSCM DLL C: \WINDOWS\SYSTEM\RPCLTSCM.DLL 4/23/99 4:38:45 PM GMT Microsoft® Windows® Operating System 78320000 - 7832a000 WSOCK32.DLL 4.10.1998 Microsoft Corporation BSD Socket API for Windows C: \WINDOWS\SYSTEM\WSOCK32.DLL 4/23/99 4:39:14 PM GMT Microsoft(R) Windows(R) Operating System 75fa0000 - 75faa000 MSWSOCK.DLL 4.10.2222 Microsoft Corporation Microsoft WinSock Extension APIs C: \WINDOWS\SYSTEM\MSWSOCK.DLL 4/23/99 4:38:30 PM GMT Microsoft(R) Windows(R) Operating System 794d0000 - 794e5000 WS2_32.DLL 4.10.2222 Microsoft Corporation Windows Socket 2.0 32-Bit DLL C: \WINDOWS\SYSTEM\WS2_32.DLL 4/23/99 4:39:13 PM GMT Microsoft(R) Windows(R) Operating System 76000000 - 76012000 WS2HELP.DLL 4.10.1998 Microsoft Corporation Windows Socket 2.0 Helper for Windows 98 C:\WINDOWS\SYSTEM\WS2HELP.DLL 4/23/99 4: 39:13 PM GMT Microsoft(R) Windows(R) Operating System 75fe0000 - 75fe6000 DIGEST.DLL 6.00.2800.1106 Microsoft Corporation Digest SSPI Authentication Package C: \WINDOWS\SYSTEM\DIGEST.DLL 8/29/02 11:21:08 AM GMT Microsoft® Windows® Operating System 007a0000 - 007b0000 MSNSSPC.DLL 6.00.7753 Microsoft Corporation MSN Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSNSSPC.DLL 4/23/99 4:38:21 PM GMT Microsoft® Internet Services 7a210000 - 7a22f000 MSAPSSPC.DLL 5.00.7729 Microsoft Corporation DPA Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSAPSSPC.DLL 4/23/99 4:38:11 PM GMT Microsoft® Internet Services 7b3f0000 - 7b401000 MSVCRT40.DLL 4.22.0000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT40.DLL 4/23/99 4:38:29 PM GMT Microsoft® Visual C++ 79660000 - 796b5000 SECUR32.DLL 4.10.2222 Microsoft Corporation Microsoft Win32 Security Services C: \WINDOWS\SYSTEM\SECUR32.DLL 4/23/99 4:37:39 PM GMT Microsoft(R) Windows(R) Operating System 7f870000 - 7f87a000 RPCSS.EXE 4.71.2900 Microsoft Corporation Distributed COM Services C: \WINDOWS\SYSTEM\RPCSS.EXE 9/1/98 6:18:39 PM GMT Microsoft(R) Windows NT(TM) Operating System 01000000 - 01005000 MSVCRT20.DLL 2.11.000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT20.DLL 4/23/99 4:37:36 PM GMT Microsoft® Visual C++ 7fc30000 - 7fc75000 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 22:13 Message: Logged In: YES user_id=31435 Kurt, which versions of Windows and winsock.dll are you using? I continue to be unable to reproduce any problem here, and there have been no other reports of this despite thousands of Python programs using sockets on Windows for a decade. I have to conclude there's something unique in your setup. FYI, sometimes virus scanners and/or "personal firewalls" cause bizarre crashes during startup or shutdown. Are you running one (or more) of those? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 20:29 Message: Logged In: YES user_id=816888 I have a working fix for this problem, but the code is a fairly ugly hack. (A terrible thing to do to such a well organized codebase). 1. I exported a fini_socket() function from the PYD DLL. 2. I cloned the dynamic lookup function to check for the optional fini_socket() name as well as the init_socket(). If found, I remember it in a global. 3. In PyImport_Cleanup() I call the fini_socket() routine (if present) before these modules start getting freed. 4. In NTInit() I add to a counter instead of using atexit() 5. fini_socket() calls NTcleanup(), which simply calls WSACleanup 'counter' times to release the winsock DLL. This works, so now I can go on with my Python study. If anyone wants my hack code, just email me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 15:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 13:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 11:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Tue Jul 8 13:19:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 05:19:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-715063 ] bsddb.first()/next() raise undocumented exception Message-ID: Bugs item #715063, was opened at 2003-04-03 23:03 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Works For Me Priority: 5 Submitted By: Christian Stork (cst) Assigned to: Gregory P. Smith (greg) Summary: bsddb.first()/next() raise undocumented exception Initial Comment: bsddb object's first() & next() methods raise an undocumented exception. Wouldn't returning None make much more sense? And shouldn't this be documented? Python 2.3a2+ (#2, Mar 21 2003, 22:13:05) [GCC 3.2.3 20030316 (Debian prerelease)] on linux2 >>> import bsddb >>> h.bsddb.hashopen("testdb") >>> h.first() ------------------------------------------------------------ Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/bsddb/__init__.py", line 134, in first rv = self.dbc.first() DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/ data pair found') Note: The same exception appeared for the equivalent dbhash methods. But I assume this should be fixed if this bug is fixed. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-08 08:19 Message: Logged In: YES user_id=12800 I sent a follow message to pybsddb-users@lists.sf.net. I made a suggestion about a transition plan and a suggestion of how to make this settable. Unfortunately, I think we should not change the default behavior for Python 2.3. Short answer: make .set_get_returns_none() take a "level" argument with the following semantics: 0 == what False means now 1 == what True means now 2 == make cursor.set() return None instead of raising an exception. Could we make this change in time for Python 2.4? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-08 01:43 Message: Logged In: YES user_id=413 hehe. good point. you can tell i haven't written pybsddb cursor code in a while, its api is not fresh in my mind. ... * greg puts on pybsddb hat I notice that my dbtables.py uses set_range such that it expects it to raise an exception, not return None. That means there are surely others out there whos code that change would break as well. How about I change the default to be consistent by having DBCursor set* methods returns None and add a set_cursor_set_returns_none() method to enable the behaviour anyone finds most convenient for their situation. Or does anyone think the default behaviour should not change? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-07 15:39 Message: Logged In: YES user_id=12800 Greg, correct me if I'm wrong but cursor.next() already has the return value issue you point out, i.e. it can return None or a tuple. My pattern has been to do stuff like this: rec = c.first() while rec: key, val = rec rec = c.next() so it doesn't bother me too much if the cursor.set() method works the same way . I think the documentation of set_get_returns_none is correct and cursor.set() should be changed to follow those rules. I'm not too concerned with backward compatibility either because this is the common .set() idiom I use: try: rec = c.set('somekey') except db.DBNotFoundError: rec = None while rec: ... This code would not break by changing .set(), but I would be able to remove the try/except. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-07 14:56 Message: Logged In: YES user_id=413 Looking in the code, no, none of the DBCursor set* methods follow set_get_returns_none() to not raise an exception. The documentation for set_get_returns_none implies that they should as they're all cursor "get" methods. All of the set methods normally return tuples of (key, data) rather than a single value. If we modify them to return None rather than raise a DBNotFoundError it makes for an annoying interface because it wouldn't always return a tuple. I'm inclined to leave the set methods as they are and fix the set_get_returns_none() documentation unless someone can come up with good examples why it should be different. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-07 13:49 Message: Logged In: YES user_id=12800 Greg, what about cursor.set() -- I don't think this follows set_get_returns_none() does it? I wonder if it should. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 20:01 Message: Logged In: YES user_id=413 DBNotFoundError derives from KeyError. The old bsddb library also raised KeyError on first/last/next calls when there was no more data rather than returning None so that interface cannot be changed. (I agree, returning None would make more sense; but I can't break the old interface). The new pybsddb interface's DB and DBEnv set_get_returns_none method does allow you to control this behaviour. If you are using the old style bsddb interface then you do not have access to the DBEnv before the DB object is created (DB objects inherit the flag setting from the DBEnv when they are created) so you'll need to call set_get_returns_none on the DB object itself: import bsddb # python 2.3 bsddb (aka bsddb3 or pybsddb) hdb = bsddb.hashopen("myhash", 'c') hdb.db.set_get_returns_none(1) # will only work on python 2.3 / pybsddb spam = hdb.first() while spam: spam = hdb.next() # notice there were no errors. I've looked at the code for first/last/prev/get and they all use the same internal DBCursor_get wrapper that obeys the set_get_returns_none flag so that you can write simple "foo = hdb.first(); while not foo: foo = hdb.next()" code. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 19:24 Message: Logged In: YES user_id=413 i'm taking a look. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-07 18:46 Message: Logged In: YES user_id=12800 pybsddb has this option to return None from cursor.get() methods instead of raising DBNotFoundError. The DBEnv method set_get_returns_none() can be used to change the behavior, although the default is to return None. I agree that this is very handy! I suppose .first() and .last() should perhaps honor this config as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 From noreply@sourceforge.net Tue Jul 8 13:21:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 05:21:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-767228 ] Pickle (cPickle) __getinitargs__ problem in 2.3b2 ? Message-ID: Bugs item #767228, was opened at 2003-07-07 17:18 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767228&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Gregor Mirai (gmirai) Assigned to: Jeremy Hylton (jhylton) Summary: Pickle (cPickle) __getinitargs__ problem in 2.3b2 ? Initial Comment: The following code works correctly with 2.3b1 (on MacOS X), but it throws KeyError: __getinitargs__ with 2.3b2 : -------------------------------------------- #!/usr/bin/env python import cPickle as c class Style: def __init__(self): self.d = {} def __setitem__(self, key, value): self.d["d_"+key]=value def __getattr__(self, key): if key.startswith("d_"): return self.d[key] else: return self.__dict__[key] s = Style() s["A"] = "B" print s.d_A print c.dumps(s) -------------------------------------------- The problem shows with any class that should override __getattr__ attribute. So it seems that pickle is broken in the new release ? ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-07-08 12:21 Message: Logged In: YES user_id=31392 This isn't a bug after all. cPickle and pickle now produce the same results, which is a KeyError. The __getattr__() method in the example code is incorrect, because it raises KeyError for missing attributes instead of AttributeError. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-07 19:14 Message: Logged In: YES user_id=31392 I probably broke something in change that catches only specific exceptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767228&group_id=5470 From noreply@sourceforge.net Tue Jul 8 13:37:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 05:37:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-764095 ] recent test_httplib change uses network Message-ID: Bugs item #764095, was opened at 2003-07-01 17:22 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764095&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Steven Taschuk (staschuk) Assigned to: Jeremy Hylton (jhylton) Summary: recent test_httplib change uses network Initial Comment: The 1.11 revision of test_httplib.py accesses www.python.org. The simplest fix is simply to add requires('network'), but the right fix imho is to mock the connection properly. I don't have a patch yet. ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-07-08 12:37 Message: Logged In: YES user_id=31392 Fixed in rev 1.12 of test_httplib.py. ---------------------------------------------------------------------- Comment By: Steven Taschuk (staschuk) Date: 2003-07-02 22:31 Message: Logged In: YES user_id=666873 Attached a patch to make the test tickle bug 622042 as desired but not access www.python.org or otherwise require the network resource. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-02 04:02 Message: Logged In: YES user_id=80475 Jeremy authored rev 1.11. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764095&group_id=5470 From noreply@sourceforge.net Tue Jul 8 15:38:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 07:38:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-767794 ] invalid break in function definition from shell acts funny Message-ID: Bugs item #767794, was opened at 2003-07-08 10:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767794&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Lloyd Hugh Allen (lha2) Assigned to: Nobody/Anonymous (nobody) Summary: invalid break in function definition from shell acts funny Initial Comment: the following function definition, typed in at an idle prompt: def broken(): print "function" break === gives the traceback Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\PyShell.py", line 595, in enter_callback self.runit() File "C:\Python22\Tools\idle\PyShell.py", line 614, in runit more = self.interp.runsource(line) File "C:\Python22\Tools\idle\PyShell.py", line 192, in runsource return InteractiveInterpreter.runsource(self, source, filename) File "C:\Python22\lib\code.py", line 79, in runsource self.showsyntaxerror(filename) File "C:\Python22\Tools\idle\PyShell.py", line 219, in showsyntaxerror pos = "iomark linestart + %d lines + %d chars" % (lineno-1, TypeError: unsupported operand type(s) for - : 'NoneType' and 'int' === above the function definition. Alt-P fails to give back the erroneous function definition. In Python 2.2.3, IDLE 0.8, windows XP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767794&group_id=5470 From noreply@sourceforge.net Tue Jul 8 16:09:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 08:09:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-767794 ] invalid break in function definition from shell acts funny Message-ID: Bugs item #767794, was opened at 2003-07-08 10:38 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767794&group_id=5470 Category: IDLE >Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lloyd Hugh Allen (lha2) >Assigned to: Kurt B. Kaiser (kbk) Summary: invalid break in function definition from shell acts funny Initial Comment: the following function definition, typed in at an idle prompt: def broken(): print "function" break === gives the traceback Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\PyShell.py", line 595, in enter_callback self.runit() File "C:\Python22\Tools\idle\PyShell.py", line 614, in runit more = self.interp.runsource(line) File "C:\Python22\Tools\idle\PyShell.py", line 192, in runsource return InteractiveInterpreter.runsource(self, source, filename) File "C:\Python22\lib\code.py", line 79, in runsource self.showsyntaxerror(filename) File "C:\Python22\Tools\idle\PyShell.py", line 219, in showsyntaxerror pos = "iomark linestart + %d lines + %d chars" % (lineno-1, TypeError: unsupported operand type(s) for - : 'NoneType' and 'int' === above the function definition. Alt-P fails to give back the erroneous function definition. In Python 2.2.3, IDLE 0.8, windows XP. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-08 11:09 Message: Logged In: YES user_id=33168 Could you test with IDLEfork or the IDLE in 2.3b2? Hopefully this problem has been fixed for 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767794&group_id=5470 From noreply@sourceforge.net Tue Jul 8 16:13:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 08:13:11 -0700 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-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@sourceforge.net Tue Jul 8 16:26:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 08:26:44 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-767592 ] unittest docs don't suggest "unittest.main()" Message-ID: Feature Requests item #767592, was opened at 2003-07-08 02:40 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=767592&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Bennetts (spiv) >Assigned to: Raymond Hettinger (rhettinger) Summary: unittest docs don't suggest "unittest.main()" Initial Comment: By far the most common use of the unittest module I've seen is simply: 1. Define one or more classes that subclass unittest.TestCase. Give them methods that are named "test_foo". 2. Put "if __name__ == '__main__': unittest.main()" at the bottom of the module. Nowhere do the unittest standard library docs make it clear this is the easiest, and most common, way to use the unittest module. The "Organizing test code" section completely fails to mention this, even though I think this should be the first thing described. Instead, it helpfully lists all sorts of ways to use test suites that you rarely, if ever, need in practice. Mention of unittest.main() is buried several sections later, and is very brief. I suggest opening "Organizing test code" with a complete working example demonstrating typical use, e.g.: --- import unittest class TestArithmetic(unittest.TestCase): def test_addition(self): self.failUnlessEqual(1+2, 3) if __name__ == '__main__': unittest.main() --- It's a trivial example, but it could work wonders. I usually recommend the diveintopython.org docs on unittest (http://diveintopython.org/roman_divein.html) due to the state of the official unittest docs. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=767592&group_id=5470 From noreply@sourceforge.net Tue Jul 8 16:30:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 08:30:11 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-616247 ] More documentation for the imp module Message-ID: Feature Requests item #616247, was opened at 2002-09-29 14:58 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=616247&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jurie Horneman (jhorneman) >Assigned to: Raymond Hettinger (rhettinger) Summary: More documentation for the imp module Initial Comment: Not all of the public functions of the imp module appear to be documented (in section 3.21, Python version 2.2). get_frozen_object load_package PY_CODERESOURCE are not documented. Also, the documentation for load_module() can be a bit confusing, partially due to inconsistent use of the word pairs 'tuple' / 'triple' and 'pathname' / 'filename'. (I did not need the abovementioned public functions, but while struggling with this module I noticed them and wondered if the documentation was outdated, or whether they held the key to my success.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=616247&group_id=5470 From noreply@sourceforge.net Tue Jul 8 18:38:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 10:38:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-767794 ] invalid break in function definition from shell acts funny Message-ID: Bugs item #767794, was opened at 2003-07-08 09:38 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767794&group_id=5470 Category: IDLE Group: Python 2.2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Lloyd Hugh Allen (lha2) Assigned to: Kurt B. Kaiser (kbk) Summary: invalid break in function definition from shell acts funny Initial Comment: the following function definition, typed in at an idle prompt: def broken(): print "function" break === gives the traceback Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\PyShell.py", line 595, in enter_callback self.runit() File "C:\Python22\Tools\idle\PyShell.py", line 614, in runit more = self.interp.runsource(line) File "C:\Python22\Tools\idle\PyShell.py", line 192, in runsource return InteractiveInterpreter.runsource(self, source, filename) File "C:\Python22\lib\code.py", line 79, in runsource self.showsyntaxerror(filename) File "C:\Python22\Tools\idle\PyShell.py", line 219, in showsyntaxerror pos = "iomark linestart + %d lines + %d chars" % (lineno-1, TypeError: unsupported operand type(s) for - : 'NoneType' and 'int' === above the function definition. Alt-P fails to give back the erroneous function definition. In Python 2.2.3, IDLE 0.8, windows XP. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-08 12:38 Message: Logged In: YES user_id=80475 In 2.3b2+, the command line version of python properly raises a SyntaxError, but in the new IDLE it doesn't get that far because the indent/dedenting is thrown off. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-08 10:09 Message: Logged In: YES user_id=33168 Could you test with IDLEfork or the IDLE in 2.3b2? Hopefully this problem has been fixed for 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767794&group_id=5470 From noreply@sourceforge.net Tue Jul 8 20:05:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 12:05:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-544248 ] gcc warning in unicodeobject.c Message-ID: Bugs item #544248, was opened at 2002-04-15 18:29 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=544248&group_id=5470 Category: Build Group: None Status: Open Resolution: None Priority: 1 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: gcc warning in unicodeobject.c Initial Comment: gcc 2.96 on Linux (RedHat 7.1) issues the following warning when compiling Objects/unicodeobject.c 2.138 (configured with --enable-unicode=ucs4) Objects/unicodeobject.c: In function `PyUnicodeUCS4_Format': Objects/unicodeobject.c:5574: warning: int format, long int arg (arg 3) Objects/unicodeobject.c:5574: warning: unsigned int format, long unsigned int arg (arg 4) ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-07-08 21:05 Message: Logged In: YES user_id=89016 The warnings seem to be gone now, with gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113) The compiler call looks like this: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-08 06:28 Message: Logged In: YES user_id=357491 Using gcc 3.1 on OS X I don't get any warnings. Anyone still getting warnings? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-06-19 19:25 Message: Logged In: YES user_id=31392 Any chance of progress here? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-18 21:22 Message: Logged In: YES user_id=89016 If all relevant implementations of sprintf() support %lx I'd say we should change PyString_FromFormatV(). But to decide that, you should definitely ask on Python-dev. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-13 15:47 Message: Logged In: YES user_id=33168 Line is 6469 in current CVS. I fixed the warning for arg 3, arg 4 is a bit harder. It requires using %lx which is not supported in PyString_FromFormatV(). I'm not sure the changes are worthwhile (that's why I didn't make the change). To fix PyString_FromFormatV(), these changes are required: Line 194: - if (*f == 'l' && *(f+1) == 'd') + if (*f == 'l' && (*(f+1) == 'd' || *(f+1) == 'x')) Line: 266 - if (*f == 'l' && *(f+1) == 'd') { + if (*f == 'l' && (*(f+1) == 'd' || *(f+1) == 'x')) { Line: 287 - sprintf(s, "%x", va_arg(vargs, int)); + if (longflag) + sprintf(s, "%lx", va_arg(vargs, unsigned long)); + else + sprintf(s, "%x", va_arg(vargs, unsigned) ); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=544248&group_id=5470 From noreply@sourceforge.net Tue Jul 8 21:21:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 13:21:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-767563 ] [win32] some .dsp files have unix line endings Message-ID: Bugs item #767563, was opened at 2003-07-08 01:21 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767563&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tim Evans (tim_evans) >Assigned to: Tim Peters (tim_one) Summary: [win32] some .dsp files have unix line endings Initial Comment: Some of the .dsp (DevStudio Project) files in the source .tgz for Python 2.3b2 have unix line endings instead of dos. "_csv.dsp" is one such file. This causes DevStudio to fail to load them correctly, and prevents those modules from beign built. Running unix2dos the .dsp files fixed the problem. I may have noticed this where others didn't because I unpacked the .tgz on a linux file server and then compiled on a WinXP client. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-08 16:21 Message: Logged In: YES user_id=31435 I cvs admin -kb'ed _bsddb.dsp _csv.dsp _ssl.dsp bz2.dsp datetime.dsp from a Windows box. That should cure it. If it doesn't, I don't really care . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767563&group_id=5470 From noreply@sourceforge.net Tue Jul 8 21:28:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 13:28:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-766891 ] oct() function does not represent zero correctly Message-ID: Bugs item #766891, was opened at 2003-07-06 20:35 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766891&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Joshua Biagio (roehnan) Assigned to: Nobody/Anonymous (nobody) Summary: oct() function does not represent zero correctly Initial Comment: Under python 2.3b2, the oct() function does not return '00' for 0 as the grammar specifies, but simply '0'. I believe this to be a bug because the hex() function returns '0x0' for zero. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-08 16:28 Message: Logged In: YES user_id=31435 Indeed, changing this would improve nothing and break currently working code, so closing it. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-08 01:46 Message: Logged In: YES user_id=80475 The grammar does specify "0" followed by one or more octdigits; however, that serves only to tell the interpreter how to convert a string into an internal representation. Since "00" and "0" unambiguously convert to zero, there is no harm with the current situation. On the contrary, attempts to "repair" this one may hurt existing programs relying on the current behavior. I recommend marking this one as Won't Fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766891&group_id=5470 From noreply@sourceforge.net Tue Jul 8 22:44:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 14:44:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-768068 ] Explicit interp reference during build fails Message-ID: Bugs item #768068, was opened at 2003-07-08 16: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=768068&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Jack Jansen (jackjansen) Summary: Explicit interp reference during build fails Initial Comment: I think this is MacPython-specific and not just a general Python build issue. If I explicitly reference the Python executable when building an out-of-tree extension module I get an error building the .so file because it stripped the dirname() of the python.exe file. Here's a simple example. I have a directory with a single extension module and simple setup.py. I want to build it with ~/src/python/head/dist/src/build.pg/python.exe Compilation works fine. Linkage bombs. % pwd /Users/skip/src/PyExtensions1.5/python2.2 montanaro:python2.2% ls -l total 8 -rw-r--r-- 1 skip staff 1318 Jan 21 2002 llopmodule.c -rw-rw-r-- 1 skip staff 114 Jan 21 2002 setup.py montanaro:python2.2% cat setup.py from distutils.core import setup, Extension setup(name="llop", ext_modules=[Extension("llop", ["llopmodule.c"])]) montanaro:python2.2% ~/src/python/head/dist/src/ build.pg/python.exe setup.py build running build running build_ext building 'llop' extension creating build creating build/temp.darwin-6.6-Power_Macintosh-2.3 gcc -pg -fno-strict-aliasing -Wno-long-double -no-cpp- precomp -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/ Users/skip/src/python/head/dist/src/Include -I/Users/skip/ src/python/head/dist/src/build.pg -c llopmodule.c -o build/ temp.darwin-6.6-Power_Macintosh-2.3/llopmodule.o creating build/lib.darwin-6.6-Power_Macintosh-2.3 gcc -pg -bundle -bundle_loader python.exe build/ temp.darwin-6.6-Power_Macintosh-2.3/llopmodule.o -o build/lib.darwin-6.6-Power_Macintosh-2.3/llop.so ld: can't open: python.exe (No such file or directory, errno = 2) error: command 'gcc' failed with exit status 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768068&group_id=5470 From noreply@sourceforge.net Wed Jul 9 02:33:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 18:33:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-544248 ] gcc warning in unicodeobject.c Message-ID: Bugs item #544248, was opened at 2002-04-15 09:29 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=544248&group_id=5470 Category: Build Group: None >Status: Closed >Resolution: Out of Date Priority: 1 Submitted By: Walter Dörwald (doerwalter) Assigned to: Nobody/Anonymous (nobody) Summary: gcc warning in unicodeobject.c Initial Comment: gcc 2.96 on Linux (RedHat 7.1) issues the following warning when compiling Objects/unicodeobject.c 2.138 (configured with --enable-unicode=ucs4) Objects/unicodeobject.c: In function `PyUnicodeUCS4_Format': Objects/unicodeobject.c:5574: warning: int format, long int arg (arg 3) Objects/unicodeobject.c:5574: warning: unsigned int format, long unsigned int arg (arg 4) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-08 18:33 Message: Logged In: YES user_id=357491 OK, I am going to close this then. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-08 12:05 Message: Logged In: YES user_id=89016 The warnings seem to be gone now, with gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113) The compiler call looks like this: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-07 21:28 Message: Logged In: YES user_id=357491 Using gcc 3.1 on OS X I don't get any warnings. Anyone still getting warnings? ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-06-19 10:25 Message: Logged In: YES user_id=31392 Any chance of progress here? ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2002-09-18 12:22 Message: Logged In: YES user_id=89016 If all relevant implementations of sprintf() support %lx I'd say we should change PyString_FromFormatV(). But to decide that, you should definitely ask on Python-dev. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-13 06:47 Message: Logged In: YES user_id=33168 Line is 6469 in current CVS. I fixed the warning for arg 3, arg 4 is a bit harder. It requires using %lx which is not supported in PyString_FromFormatV(). I'm not sure the changes are worthwhile (that's why I didn't make the change). To fix PyString_FromFormatV(), these changes are required: Line 194: - if (*f == 'l' && *(f+1) == 'd') + if (*f == 'l' && (*(f+1) == 'd' || *(f+1) == 'x')) Line: 266 - if (*f == 'l' && *(f+1) == 'd') { + if (*f == 'l' && (*(f+1) == 'd' || *(f+1) == 'x')) { Line: 287 - sprintf(s, "%x", va_arg(vargs, int)); + if (longflag) + sprintf(s, "%lx", va_arg(vargs, unsigned long)); + else + sprintf(s, "%x", va_arg(vargs, unsigned) ); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=544248&group_id=5470 From noreply@sourceforge.net Wed Jul 9 05:27:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 21:27:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-767794 ] Break or Continue Outside Loop Causes Crash Message-ID: Bugs item #767794, was opened at 2003-07-08 09:38 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767794&group_id=5470 Category: IDLE Group: Python 2.2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Lloyd Hugh Allen (lha2) Assigned to: Kurt B. Kaiser (kbk) >Summary: Break or Continue Outside Loop Causes Crash Initial Comment: the following function definition, typed in at an idle prompt: def broken(): print "function" break === gives the traceback Exception in Tkinter callback Traceback (most recent call last): File "C:\Python22\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\Python22\Tools\idle\PyShell.py", line 595, in enter_callback self.runit() File "C:\Python22\Tools\idle\PyShell.py", line 614, in runit more = self.interp.runsource(line) File "C:\Python22\Tools\idle\PyShell.py", line 192, in runsource return InteractiveInterpreter.runsource(self, source, filename) File "C:\Python22\lib\code.py", line 79, in runsource self.showsyntaxerror(filename) File "C:\Python22\Tools\idle\PyShell.py", line 219, in showsyntaxerror pos = "iomark linestart + %d lines + %d chars" % (lineno-1, TypeError: unsupported operand type(s) for - : 'NoneType' and 'int' === above the function definition. Alt-P fails to give back the erroneous function definition. In Python 2.2.3, IDLE 0.8, windows XP. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-08 23:27 Message: Logged In: YES user_id=149084 SyntaxErrors involving break/continue outside a loop don't return the offset value. PyShell.py Rev 1.79 ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-08 12:38 Message: Logged In: YES user_id=80475 In 2.3b2+, the command line version of python properly raises a SyntaxError, but in the new IDLE it doesn't get that far because the indent/dedenting is thrown off. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-08 10:09 Message: Logged In: YES user_id=33168 Could you test with IDLEfork or the IDLE in 2.3b2? Hopefully this problem has been fixed for 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767794&group_id=5470 From noreply@sourceforge.net Wed Jul 9 05:51:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 21:51:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-619713 ] Import fails in Idle Message-ID: Bugs item #619713, was opened at 2002-10-07 09:15 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 Category: IDLE Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Leslie Brooks (lesliebrooks) >Assigned to: Kurt B. Kaiser (kbk) Summary: Import fails in Idle Initial Comment: The import command works in the command line interpreter, but fails in Idle: >>> os.listdir('.') ['Debug', 'example.cxx', 'example.dsp', 'example.h', 'example.i', 'example.ncb', 'example.py', 'example.pyc', 'example.sln', 'example.suo', 'example.vcproj', 'example_wrap.cxx', 'foo', 'index.html', 'Makefile', 'runme.py', '_example.dll', '_example.ilk'] >>> import _example Traceback (most recent call last): File "", line 1, in ? import _example ImportError: No module named _example >>> I have gotten it to work _once_ in Idle, but was never able to repeat it. I am running Python 2.2.1 under Win2K (5.00.2195 SP3). ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-08 23:51 Message: Logged In: YES user_id=149084 .../Lib/idlelib PyShell.py Rev 1.67 Also fixed in IDLEfork. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-12-19 13:07 Message: Logged In: YES user_id=149084 In W2K I changed the Start In item in the IDLE button properties to d:\mydoc\PythonFiles, and then ran a short script saved in that directory. Note that the Start In directory becomes sys.path[1]. I'm looking at a cleaner way to do this in Idlefork, probably by adding the directory of the current file to sys.path. You could also frob IDLE's sys.path. Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import sys >>> sys.path ['D:\PROGRA~1\PYTHON\Tools\idle', 'D:\mydoc\PythonFiles', 'D:\Program Files\Python\DLLs', 'D:\Program Files\Python\lib', 'D:\Program Files\Python\lib\lib- tk', 'D:\Program Files\Python', 'D:\Program Files\Python\lib\site- packages'] >>> import foo Foo is a script which will print its current working directory D:\mydoc\PythonFiles >>> import os >>> os.listdir(".") ['foo.py', 'foo.pyc'] >>> ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-12-18 20:17 Message: Logged In: YES user_id=149084 On Linux, using 2.2.1, I don't see the problem. IDLE starts with '' as sys.path[0] and expands it to the absolute path of the directory in which it was started. Idlefork on Linux is the same. Python 2.2.1 (#1, Dec 14 2002, 21:10:27) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> import sys >>> sys.path ['/home/kbk', '/usr/lib/python2.2/Tools/idle', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', '/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', '/usr/lib/python2.2/site-packages'] >>> ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-12-14 20:39 Message: Logged In: YES user_id=33168 Leslie, do you have this problem with 2.2.2? If so, can you try idlefork? See http://sf.net/projects/idlefork ---------------------------------------------------------------------- Comment By: Leslie Brooks (lesliebrooks) Date: 2002-10-14 08:15 Message: Logged In: YES user_id=271417 > Date: 2002-10-13 09:02 > Sender: jepler > Logged In: YES > user_id=2772 > > Don't shared modules need the extension .pyd instead of .dll? > No, I am able to load the .dll from the command line version of Python. Also: >>> imp.get_suffixes() [('.pyd', 'rb', 3), ('.dll', 'rb', 3), ('.py', 'r', 1), ('.pyw', 'r', 1), ('.pyc', 'rb', 2)] shows that Python is searching for DLLs. > Is sys.path[0] some absolute directory (the one containing > idle.py, for instance) instead of '.'? > Ahh, that is the true problem. sys.path in Idle is: >>> sys.path ['C:\PROGRA~1\Python22\Tools\idle', 'C:\PROGRA~1\Python22', 'C:\Program Files\Python22\DLLs', 'C:\Program Files\Python22\lib', 'C:\Program Files\Python22\lib\lib-tk', 'C:\Program Files\Python22', 'C:\Program Files \Python22\lib\site-packages'] while sys.path in the command line interpreter is: >>> sys.path ['', 'C:\PROGRA~1\Python22', 'C:\Program Files\Python22\DLLs', 'C:\Program Files\Python22\lib', 'C:\Program Files\Python22\lib\lib-tk', 'C:\Program Files\Python22', 'C:\Program Files\Python22\lib\site-packages'] So the correct title for this bug report should be "Idle replaces sys.path[0] rather than appending a new entry to the list". This means that programs that work when run through the command-line interpreter may break quite dramatically when run from Idle, and vice versa. Leslie ---------------------------------------------------------------------- Comment By: Jeff Epler (jepler) Date: 2002-10-13 08:02 Message: Logged In: YES user_id=2772 Don't shared modules need the extension .pyd instead of .dll? Is sys.path[0] some absolute directory (the one containing idle.py, for instance) instead of '.'? Is there a way to run idle with -v so that it lists directories and files it tries to import as modules? ---------------------------------------------------------------------- Comment By: Leslie Brooks (lesliebrooks) Date: 2002-10-07 16:53 Message: Logged In: YES user_id=271417 I should have noted that 'import' _does_ work to a degree - 'import os' worked. The '_example.dll' that I am trying to import is the 'shapes' example that is distributed with SWIG 1.3.15, and should import without any trouble. It does import just fine from the command line version of Python, but not from Idle. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=619713&group_id=5470 From noreply@sourceforge.net Wed Jul 9 05:58:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 21:58:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 22:32 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Kurt Grittner (grittkmg) Assigned to: Mark Hammond (mhammond) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-07-09 14:58 Message: Logged In: YES user_id=14198 Checking in socketmodule.c; new revision: 1.270; previous revision: 1.269 ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-08 21:23 Message: Logged In: YES user_id=816888 Yes! Changing: atexit(NTcleanup); to: Py_AtExit(NTcleanup); Fixes my nasty GPF! Thanks! By the way, the bad behavior isn't limited to GPF's. On every machine that I tested the echo server received a 'connection reset by peer' error instead of the orderly close that running WSACleanup() from the DLL context provides. I missed the presence of Py_AtExit()... much cleaner than my nasty hack. This is a really cool program. My compliments to the chefs. Kurt ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-08 14:35 Message: Logged In: YES user_id=14198 I also can't repro this, but do believe it. I think the patch is simple: RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.268 diff -r1.268 socketmodule.c 3292c3292 < atexit(os_cleanup); --- > Py_AtExit(os_cleanup); This will cause the cleanup function to be called during Py_Finalize(), which is never implicitly called in a DllMain. Can you let me know if this fixes it? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-08 04:05 Message: Logged In: YES user_id=816888 From: "Eugene Gershnik [SDK MVP]" References: <6hvigvgnlsqhihobl06jt1edjfsv7r4pja@4ax.com> Subject: Re: WSAStartup and WSACleanup from within a DLL Date: Mon, 7 Jul 2003 10:26:25 -0700 Lines: 24 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Newsgroups: microsoft.public.win32.programmer.networks NNTP-Posting-Host: dsl093-033-235.snd1.dsl.speakeasy.net 66.93.33.235 Path: TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl Xref: TK2MSFTNGP08.phx.gbl microsoft.public.win32. programmer.networks:43932 It is in general a bad idea. atexit() handlers are running from within DLL_PROCESS_DETACH notification and this is a bad place to clean up other DLLs. See remarks to DllMain in MSDN for details. Note that it is also a bad idea to use C++ global or static objects to startup/cleanup winsock since those als rely on atexit() for destruction. The best way to init winsock for your DLL is to have something like MyDllInit() and MyDllTerm() functions that should be called be the user of the DLL. Eugene Kurt Grittner wrote: > Hello Group, > > If you call all of your socket functions from within a DLL, and you > do the WSAStartup() inside the DLL, is it legal to then have your > WSACleanup() run via atexit(StaticFunctionInDLL)? I am getting > weird behavior (GPF) on someone else's program when they do this. > The WSACleanup ends up getting called from crt0dat. Any Opinions? > > Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 19:34 Message: Logged In: YES user_id=816888 Here is a small windows project that causes the error for me on my faster machines. I will try it on a bunch of other machines. badsock good Runs it the good way badsock bad or just plain badsock Causes the error for me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 16:13 Message: Logged In: YES user_id=816888 Well, Python is new to me, but Win32 isn't. My theory for why it fails is simply that the program breaks the rules and creates a window for failure. On my system the window is large. On yours, the window is smaller. This is a machine with lots of memory. (AMD XP2000, 512MB RAM). It has a new hard drive with an on board 8MB cache. Things happen fast on this machine. This single fact could explain why the failure condition always wins the race for me. The machines at work (which also fail) are similar. Who puts win98SE on a brand new machine these days? Hmmm... maybe not too many people. I can turn your argument around... I have dozens of network programs running on this machine, many of which I wrote, none of which play fast-and-loose with threaded-DLL's, all of which work. Python is the only network program that fails. It fails every single time. I luckily have access to the source, so I can find the bug and fix it. Great! The wonders of open source. Well, anyhow, I was only trying to lend a hand. Python looks promising. I am looking at it as a potential replacement for VB/ActiveX. I am going to try this on some older, slower machines. Also, I will attempt to code a demo program that reproduces the bad behavior by duplicating the steps taken in the socketmodule, and hopefully also duplicating the error on more machines. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-07 14:26 Message: Logged In: YES user_id=31435 Mark, can you take a look at this? If you agree the design is hosed, it would be good to fix it before 2.3r1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-07 14:21 Message: Logged In: YES user_id=31435 You're trying too hard . I'm not arguing about the design (for one thing, it's not my design, and I don't know anything about it), I'm wondering both why I can't reproduce a problem, and especially why no other report of this has ever been made. You surely don't believe you're the only programmer to try sockets in Python on Windows, right? I also tried it under an up-to-date Win98SE, also with MSVC 6 and all current IE 6 patches. Indeed, that's the machine I've built the PythonLabs Windows installer *on* for the last two years. No problem. Everyone who has ever run the Python test suite on Windows has exercised sockets on Windows, and so has anyone who has ever run Zope on Windows, etc. It may indeed be a bit of Rocket Science if you don't have a theory for why it fails only when you run it! The reason I'm keen to know is that only someone who can see the problem can test a putative fix (and so confirm-- or refute --that the problem goes away). ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 14:00 Message: Logged In: YES user_id=816888 Umm, this is not rocket science. WSACleanup() is being called in the wrong context. Startup is called in a DLL context. That puts the info in Thread Local Storage (TLS). The DLL Is allowed to unload with an atexit() pointer still pending to it. This is bad design. You should always call startup/cleanup in pairs and in the same thread context. As I said before this happens on every win98SE machine that I have tried it on. I have no firewall or virus scanner. This is a fairly recent installation of win98 with all of the MS updates for I.E. Apart from that, the most unusual thing is the presence of the VisualStudio 6.0 suite of programs. I can do a new install of win98SE on an old machine, just out of curiosity, but you only have to read this web site to see that this design for startup/cleanup calls is a recipie for disaster: http://support.microsoft.com/default.aspx?scid=http: //support.microsoft.com:80/support/kb/articles/Q237/5/72. ASP&NoWebContent=1 Here is a list of some of the modules running on my machine: USER32.DLL 4.10.2227 Microsoft Corporation Win32 USER32 core component C:\WINDOWS\SYSTEM\USER32. DLL 4/21/00 3:33:18 PM GMT Microsoft(R) Windows(R) Operating System bfc00000 - bfc11000 GDI32.DLL 4.10.1998 Microsoft Corporation Win32 GDI core component C:\WINDOWS\SYSTEM\GDI32. DLL 4/23/98 4:24:18 AM GMT Microsoft(R) Windows(R) Operating System bff20000 - bff46000 ADVAPI32.DLL 4.80.1675 Microsoft Corporation Win32 ADVAPI32 core component C: \WINDOWS\SYSTEM\ADVAPI32.DLL 4/23/99 4:37:33 PM GMT Microsoft(R) Windows(R) Operating System bfe80000 - bfe90000 KERNEL32.DLL 4.10.2222 Microsoft Corporation Win32 Kernel core component C: \WINDOWS\SYSTEM\KERNEL32.DLL 4/23/99 12:45:39 AM GMT Microsoft(R) Windows(R) Operating System bff70000 - bffe3000 MPR.DLL 4.10.1998 Microsoft Corporation WIN32 Network Interface DLL C:\WINDOWS\SYSTEM\MPR. DLL 4/23/99 4:37:36 PM GMT Microsoft(R) Windows(R) Operating System 7fbf0000 - 7fbfe000 MSNP32.DLL 4.10.2222 Microsoft Corporation Network provider for Microsoft networks C:\WINDOWS\SYSTEM\MSNP32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fb20000 - 7fb34000 MSNET32.DLL 4.10.2224 Microsoft Corporation Microsoft 32-bit Network API Library C: \WINDOWS\SYSTEM\MSNET32.DLL 11/12/99 4:15:15 AM GMT Microsoft(R) Windows(R) Operating System 7f300000 - 7f313000 MPREXE.EXE 4.10.1998 Microsoft Corporation WIN32 Network Interface Service Process C:\WINDOWS\SYSTEM\MPREXE.EXE 4/23/98 2:19:38 AM GMT Microsoft(R) Windows(R) Operating System 00500000 - 00507000 MPRSERV.DLL 4.10.2222 Microsoft Corporation Multinet Router C: \WINDOWS\SYSTEM\MPRSERV.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fad0000 - 7faf6000 NETAPI32.DLL 4.10.1998 Microsoft Corporation 32-bit network API DLL C: \WINDOWS\SYSTEM\NETAPI32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7f990000 - 7f995000 NETBIOS.DLL C:\WINDOWS\SYSTEM\NETBIOS. DLL 4/23/99 4:37:39 PM GMT 7f840000 - 7f848000 RNR20.DLL 4.10.2222 Microsoft Corporation Windows Socket2 NameSpace DLL C: \WINDOWS\SYSTEM\RNR20.DLL 4/23/99 4:38:44 PM GMT Microsoft(R) Windows(R) Operating System 783c0000 - 783cf000 MSAFD.DLL 4.10.1998 Microsoft Corporation Microsoft Windows Sockets 2.0 Service Provider C:\WINDOWS\SYSTEM\MSAFD.DLL 4/23/99 4: 38:11 PM GMT Microsoft(R) Windows(R) Operating System 7b410000 - 7b41b000 RPCLTSCM.DLL 4.71.2900 Microsoft Corporation Remote Process Control LTSCM DLL C: \WINDOWS\SYSTEM\RPCLTSCM.DLL 4/23/99 4:38:45 PM GMT Microsoft® Windows® Operating System 78320000 - 7832a000 WSOCK32.DLL 4.10.1998 Microsoft Corporation BSD Socket API for Windows C: \WINDOWS\SYSTEM\WSOCK32.DLL 4/23/99 4:39:14 PM GMT Microsoft(R) Windows(R) Operating System 75fa0000 - 75faa000 MSWSOCK.DLL 4.10.2222 Microsoft Corporation Microsoft WinSock Extension APIs C: \WINDOWS\SYSTEM\MSWSOCK.DLL 4/23/99 4:38:30 PM GMT Microsoft(R) Windows(R) Operating System 794d0000 - 794e5000 WS2_32.DLL 4.10.2222 Microsoft Corporation Windows Socket 2.0 32-Bit DLL C: \WINDOWS\SYSTEM\WS2_32.DLL 4/23/99 4:39:13 PM GMT Microsoft(R) Windows(R) Operating System 76000000 - 76012000 WS2HELP.DLL 4.10.1998 Microsoft Corporation Windows Socket 2.0 Helper for Windows 98 C:\WINDOWS\SYSTEM\WS2HELP.DLL 4/23/99 4: 39:13 PM GMT Microsoft(R) Windows(R) Operating System 75fe0000 - 75fe6000 DIGEST.DLL 6.00.2800.1106 Microsoft Corporation Digest SSPI Authentication Package C: \WINDOWS\SYSTEM\DIGEST.DLL 8/29/02 11:21:08 AM GMT Microsoft® Windows® Operating System 007a0000 - 007b0000 MSNSSPC.DLL 6.00.7753 Microsoft Corporation MSN Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSNSSPC.DLL 4/23/99 4:38:21 PM GMT Microsoft® Internet Services 7a210000 - 7a22f000 MSAPSSPC.DLL 5.00.7729 Microsoft Corporation DPA Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSAPSSPC.DLL 4/23/99 4:38:11 PM GMT Microsoft® Internet Services 7b3f0000 - 7b401000 MSVCRT40.DLL 4.22.0000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT40.DLL 4/23/99 4:38:29 PM GMT Microsoft® Visual C++ 79660000 - 796b5000 SECUR32.DLL 4.10.2222 Microsoft Corporation Microsoft Win32 Security Services C: \WINDOWS\SYSTEM\SECUR32.DLL 4/23/99 4:37:39 PM GMT Microsoft(R) Windows(R) Operating System 7f870000 - 7f87a000 RPCSS.EXE 4.71.2900 Microsoft Corporation Distributed COM Services C: \WINDOWS\SYSTEM\RPCSS.EXE 9/1/98 6:18:39 PM GMT Microsoft(R) Windows NT(TM) Operating System 01000000 - 01005000 MSVCRT20.DLL 2.11.000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT20.DLL 4/23/99 4:37:36 PM GMT Microsoft® Visual C++ 7fc30000 - 7fc75000 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-07 13:13 Message: Logged In: YES user_id=31435 Kurt, which versions of Windows and winsock.dll are you using? I continue to be unable to reproduce any problem here, and there have been no other reports of this despite thousands of Python programs using sockets on Windows for a decade. I have to conclude there's something unique in your setup. FYI, sometimes virus scanners and/or "personal firewalls" cause bizarre crashes during startup or shutdown. Are you running one (or more) of those? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 11:29 Message: Logged In: YES user_id=816888 I have a working fix for this problem, but the code is a fairly ugly hack. (A terrible thing to do to such a well organized codebase). 1. I exported a fini_socket() function from the PYD DLL. 2. I cloned the dynamic lookup function to check for the optional fini_socket() name as well as the init_socket(). If found, I remember it in a global. 3. In PyImport_Cleanup() I call the fini_socket() routine (if present) before these modules start getting freed. 4. In NTInit() I add to a counter instead of using atexit() 5. fini_socket() calls NTcleanup(), which simply calls WSACleanup 'counter' times to release the winsock DLL. This works, so now I can go on with my Python study. If anyone wants my hack code, just email me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 06:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 04:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-07 02:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Wed Jul 9 06:48:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 22:48:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-764504 ] doctest fails with TypeError Message-ID: Bugs item #764504, was opened at 2003-07-02 05:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764504&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark J (average) >Assigned to: Tim Peters (tim_one) Summary: doctest fails with TypeError Initial Comment: #mymod.py: class base(dict): myupdate = dict.update #FINE def myfunc(self): pass class derive(base): myname = base.myfunc #FAILS import doctest, mymod doctest.testmod(mymod) ****** $ python2.3b2 mymod.py Traceback (most recent call last): File "mymod.py", line 8, in ? import doctest, mymod File "/home/me/mymod.py", line 9, in ? doctest.testmod(mymod) File "/usr/local/lib/python2.3/doctest.py", line 1137, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/local/lib/python2.3/doctest.py", line 900, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/local/lib/python2.3/doctest.py", line 1061, in __runone return self.rundoc(target, name) File "/usr/local/lib/python2.3/doctest.py", line 820, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/local/lib/python2.3/doctest.py", line 929, in run__test__ raise TypeError("Tester.run__test__: values in " TypeError: Tester.run__test__: values in dict must be strings, functions or classes; ****** Does not appear to be specific to Python v2.3. Thanks! Mark ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 00:48 Message: Logged In: YES user_id=80475 Tim, would you like me to fix this one by searching the unbound method or by skipping the unbound method? Since classes are searched recursively, it may be reasonable to search the unbound method. However, imports are not searched, so there is a precedent for skipping it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764504&group_id=5470 From noreply@sourceforge.net Wed Jul 9 06:50:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 22:50:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http Message-ID: Bugs item #767111, was opened at 2003-07-07 07:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: AttributeError thrown by urllib.open_http Initial Comment: In 2.3b2, looks like an error condition isn't being picked up on line 300 or 301 of urllib.py. The code that triggered this traceback was simply: url = urllib.urlopen(action, data) Traceback (most recent call last): File "autospamrep.py", line 170, in ? current_page = handle_spamcop_page(current_page) File "autospamrep.py", line 140, in handle_spamcop_page url = urllib.urlopen(action, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 78, in urlopen return opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 183, in open return getattr(self, name)(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 308, in open_http return self.http_error(url, fp, errcode, errmsg, headers, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 00:50 Message: Logged In: YES user_id=80475 What were the values of 'action' and 'data' when the call was made? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 From noreply@sourceforge.net Wed Jul 9 07:06:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 23:06:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-715063 ] bsddb.first()/next() raise undocumented exception Message-ID: Bugs item #715063, was opened at 2003-04-03 20:03 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christian Stork (cst) Assigned to: Gregory P. Smith (greg) Summary: bsddb.first()/next() raise undocumented exception Initial Comment: bsddb object's first() & next() methods raise an undocumented exception. Wouldn't returning None make much more sense? And shouldn't this be documented? Python 2.3a2+ (#2, Mar 21 2003, 22:13:05) [GCC 3.2.3 20030316 (Debian prerelease)] on linux2 >>> import bsddb >>> h.bsddb.hashopen("testdb") >>> h.first() ------------------------------------------------------------ Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.3/bsddb/__init__.py", line 134, in first rv = self.dbc.first() DBNotFoundError: (-30991, 'DB_NOTFOUND: No matching key/ data pair found') Note: The same exception appeared for the equivalent dbhash methods. But I assume this should be fixed if this bug is fixed. ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2003-07-08 23:06 Message: Logged In: YES user_id=413 resolved/discussed in greater detail on the mailing list. I extended set_get_returns_none as barry suggested to take the values 0, 1 and 2. The current default is 1. The default will change to 2 in the future (pybsddb 4.2 & python 2.4 timeframe). ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-08 05:19 Message: Logged In: YES user_id=12800 I sent a follow message to pybsddb-users@lists.sf.net. I made a suggestion about a transition plan and a suggestion of how to make this settable. Unfortunately, I think we should not change the default behavior for Python 2.3. Short answer: make .set_get_returns_none() take a "level" argument with the following semantics: 0 == what False means now 1 == what True means now 2 == make cursor.set() return None instead of raising an exception. Could we make this change in time for Python 2.4? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-07 22:43 Message: Logged In: YES user_id=413 hehe. good point. you can tell i haven't written pybsddb cursor code in a while, its api is not fresh in my mind. ... * greg puts on pybsddb hat I notice that my dbtables.py uses set_range such that it expects it to raise an exception, not return None. That means there are surely others out there whos code that change would break as well. How about I change the default to be consistent by having DBCursor set* methods returns None and add a set_cursor_set_returns_none() method to enable the behaviour anyone finds most convenient for their situation. Or does anyone think the default behaviour should not change? ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-07 12:39 Message: Logged In: YES user_id=12800 Greg, correct me if I'm wrong but cursor.next() already has the return value issue you point out, i.e. it can return None or a tuple. My pattern has been to do stuff like this: rec = c.first() while rec: key, val = rec rec = c.next() so it doesn't bother me too much if the cursor.set() method works the same way . I think the documentation of set_get_returns_none is correct and cursor.set() should be changed to follow those rules. I'm not too concerned with backward compatibility either because this is the common .set() idiom I use: try: rec = c.set('somekey') except db.DBNotFoundError: rec = None while rec: ... This code would not break by changing .set(), but I would be able to remove the try/except. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-07 11:56 Message: Logged In: YES user_id=413 Looking in the code, no, none of the DBCursor set* methods follow set_get_returns_none() to not raise an exception. The documentation for set_get_returns_none implies that they should as they're all cursor "get" methods. All of the set methods normally return tuples of (key, data) rather than a single value. If we modify them to return None rather than raise a DBNotFoundError it makes for an annoying interface because it wouldn't always return a tuple. I'm inclined to leave the set methods as they are and fix the set_get_returns_none() documentation unless someone can come up with good examples why it should be different. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-07 10:49 Message: Logged In: YES user_id=12800 Greg, what about cursor.set() -- I don't think this follows set_get_returns_none() does it? I wonder if it should. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 17:01 Message: Logged In: YES user_id=413 DBNotFoundError derives from KeyError. The old bsddb library also raised KeyError on first/last/next calls when there was no more data rather than returning None so that interface cannot be changed. (I agree, returning None would make more sense; but I can't break the old interface). The new pybsddb interface's DB and DBEnv set_get_returns_none method does allow you to control this behaviour. If you are using the old style bsddb interface then you do not have access to the DBEnv before the DB object is created (DB objects inherit the flag setting from the DBEnv when they are created) so you'll need to call set_get_returns_none on the DB object itself: import bsddb # python 2.3 bsddb (aka bsddb3 or pybsddb) hdb = bsddb.hashopen("myhash", 'c') hdb.db.set_get_returns_none(1) # will only work on python 2.3 / pybsddb spam = hdb.first() while spam: spam = hdb.next() # notice there were no errors. I've looked at the code for first/last/prev/get and they all use the same internal DBCursor_get wrapper that obeys the set_get_returns_none flag so that you can write simple "foo = hdb.first(); while not foo: foo = hdb.next()" code. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2003-07-06 16:24 Message: Logged In: YES user_id=413 i'm taking a look. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-07 15:46 Message: Logged In: YES user_id=12800 pybsddb has this option to return None from cursor.get() methods instead of raising DBNotFoundError. The DBEnv method set_get_returns_none() can be used to change the behavior, although the default is to return None. I agree that this is very handy! I suppose .first() and .last() should perhaps honor this config as well? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=715063&group_id=5470 From noreply@sourceforge.net Wed Jul 9 07:18:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 23:18:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-716587 ] profile.run makes assumption regarding namespace Message-ID: Bugs item #716587, was opened at 2003-04-07 01:56 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Greg Fortune (gregfortune) >Assigned to: Guido van Rossum (gvanrossum) Summary: profile.run makes assumption regarding namespace Initial Comment: When profile.run() is executed, it assumes that the local and global namespace should be determined from the locals and globals for __main__. In the case of an embedded interpreter, this is an annoying assumption. For instance, I have a PyQt program that has an embedded interpreter running as a "debug" console and need to profile a little segement of misbehaving code. With direct access to all the gui interactively, it seemed like a simple task of profiling a function call on one of my gui elements, but the namespace in the interpreter is very different from that of the main application. A simple fix is to allow profile.run to be executed with an optional dict so the user can give their own namespace. A diff -u is attached which accomplishes this. Note that this problem appears in the current Python CVS on sourceforge, but exists at least as early as Python 2.2. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 01:18 Message: Logged In: YES user_id=80475 This seems like a reasonable request. The use case is uncommon but I don't like having __main__ hardwired in the code. What do you think? If you want the change, should it be put into Py2.3? ---------------------------------------------------------------------- Comment By: Greg Fortune (gregfortune) Date: 2003-04-07 09:36 Message: Logged In: YES user_id=155459 Doh, sorry about that. Guess I should actually check it after I submit... ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-04-07 07:31 Message: Logged In: YES user_id=6656 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=716587&group_id=5470 From noreply@sourceforge.net Wed Jul 9 07:24:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 23:24:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-755564 ] Tutorial: 4.7.2 Keyword Arguments **name output order wrong Message-ID: Bugs item #755564, was opened at 2003-06-16 16:53 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755564&group_id=5470 Category: Documentation Group: Not a Bug Status: Open Resolution: None Priority: 3 Submitted By: Jan Mattila (kakkonen) >Assigned to: Raymond Hettinger (rhettinger) Summary: Tutorial: 4.7.2 Keyword Arguments **name output order wrong Initial Comment: In the Tutorial at chapter 4.7.2 Keyword Arguments, there is an example about the formal parameter **name. I'm quoting the whole thing, for quick reference: --- begin extract from Tutorial --- def cheeseshop(kind, *arguments, **keywords): print "-- Do you have any", kind, '?' print "-- I'm sorry, we're all out of", kind for arg in arguments: print arg print '-'*40 for kw in keywords.keys(): print kw, ':', keywords[kw] It could be called like this: cheeseshop('Limburger', "It's very runny, sir.", "It's really very, VERY runny, sir.", client='John Cleese', shopkeeper='Michael Palin', sketch='Cheese Shop Sketch') and of course it would print: -- Do you have any Limburger ? -- I'm sorry, we're all out of Limburger It's very runny, sir. It's really very, VERY runny, sir. ---------------------------------------- client : John Cleese shopkeeper : Michael Palin sketch : Cheese Shop Sketch --- end extract from Tutorial --- What it actually prints on my LFS 3.3 (linuxfromscratch) based distribution with Python 2.1.3 is --- begin print out of cheeseshop --- -- Do you have any Limburger ? -- I'm sorry, we're all out of Limburger It's very runny, sir. It's really very, VERY runny, sir. ---------------------------------------- client : John Cleese sketch : Cheese Shop Sketch shopkeeper : Michael Palin --- end print out of cheeseshop --- The problem is that the keywords[kw] list order is garbled. I tried stripping this function of the *arguments formal parameter and I got the same result. I tried different amounts of **keywords in different aphabetical orders. The resulting order does not seem to be random and does not seem to be aplhabetical nor related to the length of the **keywords or anything I could figure out. It's probably not a typo (on my part), because I copied the code straight from the Tutorial page. Now, this is not really a bug in my opinion, so I'm not expecting a fix, but I was just trying to read through the Tutorial and try all the example code and got stuck trying to figure how you could tell the print order of a formal parameter **name -type's name[kw] list. I was thinking, that maybe if someone of class wizard or higher would care to indulge me in the reason for this behaviour I could become enlightened on another aspect of Python. I'm not expecting swift replies, since this is a zero-priority glitch, but someone, somewhere, someday, maybe? No? Okay. Just a thought... So much for trying to make this short. I managed to reproduce the problem on Python 1.5.2 on Red Hat Linux 7.3.2 on linux-i386 ---------------------------------------------------------------------- Comment By: Jan Mattila (kakkonen) Date: 2003-06-17 17:10 Message: Logged In: YES user_id=802538 Right, Can you force the submitter's comments to fall in line with the rest of the comments, instead of getting pushed to the front of the que? This order breaks the chain of comments and, is IMHO more difficult to read. Be that as it may. I read a couple of these bug report thingies and felt that I should propose some text in html format if I wanted anything to go anywhere, without burdening people with genuinely important things to do. I'm attaching a file with the bit of code from the last comment and some explanatory text in html format (please excuse the language). The text is proposed to replace chapter 4.7.2 in the Python 2.1.3 Tutorial at: http://www.python.org/doc/2.1.3/tut/node6.html#SECTION006720000000000000000 N.B. There are two comments in the html, so if none are allowed in the tutorial html, you know what to do with them. -Jan P.S. I realise that putting all of this under the heading "Keyword arguments" is stretching it beyond breaking point. Thus maybe the quickest way would be to just add the text from chapter 5.4 to chapter 4.7.2, something like this: "Note that the keys() method of a dictionary object returns a list of all the keys used in the dictionary, in random order." ---------------------------------------------------------------------- Comment By: Jan Mattila (kakkonen) Date: 2003-06-17 15:04 Message: Logged In: YES user_id=802538 Thanks Christopher, Your reply solved the mystery, but I was unable to find the text you mentioned in the Tutorial at: http://www.python.org/doc/2.1.3/tut/tut.html I tried searching the whole thing, just in case, and the closest I found was this: "The keys() method of a dictionary object returns a list of all the keys used in the dictionary, in random order (if you want it sorted, just apply the sort() method to the list of keys)." But it was in chapter 5.4 Dictionaries, which is quite a way from the mystery at Chapter 4.7.2. I mean the text you quoted? would solve the mystery instantly and even shed light on how to fix it. That is, if it was in the tutorial. My question is: Can you or someone put it there? Additionally it would be nice to either exclude the sorted list from the Tutorial or add a snippet of code for reproducing the list exactly. I think this could do it (although I'm sure someone knows a better way, and that should go into the tutorial): def cheeseshop(kind, *arguments, **keywords): print "-- Do you have any", kind, '?' print "-- I'm sorry, we're all out of", kind for arg in arguments: print arg print '-'*40 info = keywords.items() info.sort() for value in info: print value[0], ':', value[1] -Jan (forgot to sign my last message...) ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-06-16 22:45 Message: Logged In: YES user_id=531881 Hi Jan- The tutorial points out: Note that the sort() method of the list of keyword argument names is called before printing the contents of the keywords dictionary; if this is not done, the order in which the arguments are printed is undefined. Not sure if a patch is necessary :) -c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755564&group_id=5470 From noreply@sourceforge.net Wed Jul 9 07:28:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 08 Jul 2003 23:28:14 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-681533 ] Additional string stuff. Message-ID: Feature Requests item #681533, was opened at 2003-02-06 03:14 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=681533&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Rejected Priority: 5 Submitted By: Jeremy Fincher (jemfinch) Assigned to: Nobody/Anonymous (nobody) Summary: Additional string stuff. Initial Comment: In a lot of my programs that mess with strings, I end up somewhere making a variable "ascii" via (string.maketrans('', '')). It's just a 256-character string comprising the ascii character set. I use it, oftentimes, simply to be able to turn the 'translate' method on strings into a 'delete' method -- if I want to, say, remove all the spaces in aString, I'd do (aString.translate(ascii, string.whitespace)). Certainly an ascii variable in the string module couldn't hurt, would fit in with ascii_letters, etc. and would at least standarize the name of the full ascii set sure to be present in many Python programs. A little further out there, but I think just as useful, would be a delete method on strings. So "foo bar baz".delete(string.whitespace) would return "foobarbaz". It would be equivalent to "foo bar baz".translate(ascii, string.whitespace), or the wildly inefficient: def delete(s, deleteChars): l = [] for c in s: if c not in deleteChars: l.append(c) return ''.join(l) Anyway, that's all I can think of. Do with it what you will. Jeremy ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 01:29 Message: Logged In: YES user_id=80475 The trend is away from including character strings as attributes -- they are instead being replaced with functions like str.isascii() or str.iswhitespace(). Also, it is so easy to construct a character list that it is not worth cluttering the string API (everything there must be documented, duplicated for unicode objects, and duplicated again for userstrings). Instead for maketrans, I would use something like this: rhchars = ''.join(map(chr, range(65,100))) So, unless compelling use cases can be found, I recommend closing this one. ---------------------------------------------------------------------- Comment By: Cherniavsky Beni (cben) Date: 2003-03-10 11:22 Message: Logged In: YES user_id=36166 Just make the interface like the translate method of unicode objects: it accepts "a mapping of Unicode ordinals to Unicode ordinals, Unicode strings or None. Unmapped characters are left untouched. Characters mapped to None are deleted.". This would make the str/unicode translate methods consistent (currently there is no way to call the method that will work for both). I have no opinion on whether implementing 1-to-n translations (like Python2.3 supports for unicode objects) is worth the trouble for plain strings. Of course, the table_string[, deletechars] interface should still be supported for compatibility. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-03-05 22:03 Message: Logged In: YES user_id=99508 Ah, yes, you're right. I never knew ASCII was only 7 bits per character. Perhaps string.all_characters? I just definitely think it should be publically available so there can be some consistency between applications that need a string of all 256 8-bit characters. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-03-05 09:13 Message: Logged In: YES user_id=45365 Note that "ascii" is definitely a bad name, as it means different things to anyone. To Python it usually means "7-bit ASCII" (as in the unicode "ascii" codec). To you it apparently means "8-bit something-or-other". I have no opinion on whether this feature is a good idea, but if it is I would suggest a name with "any" or "all" in it, and possibly "8bit" too. ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-03-04 13:25 Message: Logged In: YES user_id=99508 What's the status on this? I checked string.py, and there actually already is a value that's the 256 ASCII characters, but it's called _idmap. Might we consider changing the name of that to "ascii"? I'd be happy to make the patch. Jeremy ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-07 01:47 Message: Logged In: YES user_id=99508 I guess that's what I get for not reading the documentation :) Oh well, the other two suggestions stand :) Jeremy ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-07 00:19 Message: Logged In: YES user_id=99508 I guess that's what I get for not reading the documentation :) Oh well, the other two suggestions stand :) Jeremy ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-02-06 21:15 Message: Logged In: YES user_id=31435 Just noting that you can pass None for sep if you want to explicitly ask for the default behavior. >>> " a b c".split(None, 1) ['a', 'b c'] >>> ---------------------------------------------------------------------- Comment By: Jeremy Fincher (jemfinch) Date: 2003-02-06 04:19 Message: Logged In: YES user_id=99508 Let me also make one other suggestion: the split method on a string object has, by default, behavior that can't be replicated by passing an argument as a separator. That is, the default separated acts like re.split(r'\s+'), but it's impossible to pass any value into the method to achieve that same result. The problem arises when a user wants to use the maxsplit() parameter to the method. Because maxsplit is a positional parameter instead of a keyword parameter, the user *must* declare a separate to split on, and thus loses his ability to split on whitespace-in-general. If maxsplit was changed from being a positional parameter to being a keyword parameter, then a programmer wouldn't have to give up the default behavior of the split method in order to pass it a maxsplit. At present, negative maxsplit values don't differ in any way from split's default behavior (with no maxsplit parameter given). Thus, the keyword maxsplit could default to -1 with no breakage of code. I can't see any place where changing maxsplit to a keyword parameter would break any existing code Jeremy ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=681533&group_id=5470 From noreply@sourceforge.net Wed Jul 9 09:28:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 01:28:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-768306 ] Distutils broken on Os X Message-ID: Bugs item #768306, was opened at 2003-07-09 11: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=768306&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Rueger (torstenrueger) Assigned to: Jack Jansen (jackjansen) Summary: Distutils broken on Os X Initial Comment: Os X 10.2.6. Python 2.3b2 from http://homepages.cwi.nl/~jack/ macpython.html#beta Trying to comiple py-xml-rpc 2.8.3 from http:// sourceforge.net/projects/py-xmlrpc/ I get a ton of multiple defined symbols like: ld: multiple definitions of symbol _rpcBase64Type build/temp.darwin-6.6-Power_Macintosh-2.3/src/rpcBase64.o definition of _rpcBase64Type in section (__DATA,__data) build/temp.darwin-6.6-Power_Macintosh-2.3/src/ rpcBoolean.o definition of _rpcBase64Type in section (__DATA,__common) ld: multiple definitions of symbol _rpcBoolType ..... I tracked this down to the presence of the compile flag "- fno-common" used by the distutils. The man page for gcc states quite clearly that this is not usually an advisable flag, quote: -fno-common In C, allocate even uninitialized global variables in the data section of the object file, rather than gen- erating them as common blocks. This has the effect that if the same variable is declared (without "extern") in two different compilations, you will get an error when you link them. The only reason this might be useful is if you wish to verify that the pro- gram will work on other systems which always work this way. I have compiled and linked all files with the makefile that is also distributed in py-xmlrpc, but I had to change the link options to "-flat_namespace -undefined warning". I can help in testing a fix if someone can assist with distutils knowledge. Torsten ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768306&group_id=5470 From noreply@sourceforge.net Wed Jul 9 09:29:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 01:29:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-768307 ] ssl socket seg fault in Python2.3b2 Message-ID: Bugs item #768307, was opened at 2003-07-09 09:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768307&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Russell (mattsurf76) Assigned to: Nobody/Anonymous (nobody) Summary: ssl socket seg fault in Python2.3b2 Initial Comment: Hi, not sure this is a critical error:- if an unconnected socket is passed to socket.ssl this causes a segmenation fault on RedHat 8. from socket import * s=socket() #s.connect((url, 443)) s2=ssl(s, None, None) (exits to cmd line with seg fault message) Obvioiusly one would never want to do this! Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768307&group_id=5470 From noreply@sourceforge.net Wed Jul 9 12:39:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 04:39:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-768391 ] hardcoded python paths Message-ID: Bugs item #768391, was opened at 2003-07-09 11: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=768391&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: hardcoded python paths Initial Comment: I tried to use the new version of idle that is now integrated into 2.3b2, but I got an error when I tried to run /usr/local/lib/python2.3/idlelib/idle: % /usr/local/lib/python2.3/idlelib/idle Traceback (most recent call last): File "./idle", line 8, in ? import PyShell File "./PyShell.py", line 19, in ? from Tkinter import * File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 35, in ? import _tkinter # If this fails your Python may not be configured for Tk ImportError: No module named _tkinter I'm using python2.3b2 on MacOSX 10.2.6, compiled from source with standard options. Apparently the builtin 2.2 version of Python is being used, even though $PYTHONHOME is not set (according to the manpages, this should make it default to /usr/local, and not /usr as seems to be the case). This is due to the fact that this executable script contains a shebang declaration with a hardcoded python path: % head -1 /usr/local/lib/python2.3/idlelib/idle #!/usr/bin/python This should be replaced by the standard shebang declaration: #! /usr/bin/env python I checked to see if there were any other *.py files in /usr/local/lib/python2.3 suffering from similar problems, and found the following files to be affected: /usr/local/lib/python2.3/cgi.py: #! /usr/local/bin/python /usr/local/lib/python2.3/test/test_bz2.py: #!/usr/bin/python /usr/local/lib/python2.3/test/test_largefile.py: #!python /usr/local/lib/python2.3/test/test_optparse.py: #!/usr/bin/python The files /usr/local/bin/idle, /usr/local/bin/pydoc and /usr/local/bin/pycolor also have a hardcoded python path: % head -1 idle pycolor pydoc ==> idle <== #!/usr/local/bin/python ==> pycolor <== #!/usr/local/bin/python ==> pydoc <== #!/usr/local/bin/python These should similarly be changed to #! /usr/bin/env python ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768391&group_id=5470 From noreply@sourceforge.net Wed Jul 9 13:38:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 05:38:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-768419 ] Subtle bug in os.path.realpath on Cygwin Message-ID: Bugs item #768419, was opened at 2003-07-09 08: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=768419&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: Subtle bug in os.path.realpath on Cygwin Initial Comment: Cygwin allows mounting directories within other mount points. This can cause os.path.realpath to expand some symlinks that it shouldn't. For example: $ cd / $ mkdir X $ mkdir X/Y $ ln -s X Z $ mount C:/ /Z/Y $ ls Z/Y [...contents of C:\...] $ ls X/Y [empty directory] $ python -c "import os; print os.path.realpath('Z/Y')" /X/Y [bad because /X/Y is empty yet the original Z/Y has files] In Cygwin, the correct answer would be either 'C:\' or '/cygdrive/c/'. Conceivably this problem can happen in UNIces other than Cygwin. It would be rather annoying to fix, because it would require looking at the mount table. But I thought I would mention it anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768419&group_id=5470 From noreply@sourceforge.net Wed Jul 9 13:49:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 05:49:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-768307 ] ssl socket seg fault in Python2.3b2 Message-ID: Bugs item #768307, was opened at 2003-07-09 04:29 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768307&group_id=5470 >Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Matthew Russell (mattsurf76) >Assigned to: Neal Norwitz (nnorwitz) Summary: ssl socket seg fault in Python2.3b2 Initial Comment: Hi, not sure this is a critical error:- if an unconnected socket is passed to socket.ssl this causes a segmenation fault on RedHat 8. from socket import * s=socket() #s.connect((url, 443)) s2=ssl(s, None, None) (exits to cmd line with seg fault message) Obvioiusly one would never want to do this! Matt ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-09 08:49 Message: Logged In: YES user_id=33168 This should be fixed in version 1.13 of Modules/_ssl.c. Please test from CVS to verify. Should also be duplicate of #754870. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768307&group_id=5470 From noreply@sourceforge.net Wed Jul 9 14:14:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 06:14:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-764560 ] python treats IRIX64 and IRIX as different, but they are the Message-ID: Bugs item #764560, was opened at 2003-07-02 13:38 Message generated for change (Comment added) made by gmlack You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764560&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gordon Lack (gmlack) Assigned to: Nobody/Anonymous (nobody) Summary: python treats IRIX64 and IRIX as different, but they are the Initial Comment: Related to bug 216255 (116255?), but this goes deeper, as it refers to the *running* of python rather than just its building. If I build python on an Irix6.5 system (that is new/large) the tag "irix646" is used in the build/temp.* directory (and Lib/plat-*). This has several effects: a) the plat-irix6 directory from the standard distribution is ignored. b) running the tests on an IRIX system after compiling on an IRIX64 one causes it to rebuild everything, as it will look for temp.irix-6.5-2.2 and lib.irix-6.5-2.2 in build/ rather than the temp.irix64-6.5-2.2 and lib.irix64-6.5-2.2 which were actually built. c) running the same executable on a smaller system (a single installation, NFS mounted onto a large number of systems, for which "uname -s" returns IRIX, not IRIX64) will cause it to fail to find the </python2.2/Lib/plat-irix646 directory. (This might also affect 3rd party module installation?). IRIX and IRIX64 are the same when you build n32 binaries (which is what is built by default). Python should treat them the same. It should be possible to *configure* this OS tag at configure time (which would avoid this problem). Also, installing the "plat-irix646" directories under <> rather than <> would remove the need for such a tag in the installed files. ---------------------------------------------------------------------- >Comment By: Gordon Lack (gmlack) Date: 2003-07-09 14:14 Message: Logged In: YES user_id=88015 Ok - to fix this *particular* part of the problem turns out to be simple. (I had tried setting MACHDEP in my environment, but that fails as, if MACHDEP is set, then the configure script does not set ac_sys_system and ac_sys_release so tests on these fail to get done). So, attached is the patch which equates the two. NOTE: There are other build problems. The SGI C linker (and OSF1) uses -rpath not -R, and the extension buuilding scripts don't knwo how to handle this...but I suppose these would be for a different bug report. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 17:32 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=105470&aid=764560&group_id=5470 From noreply@sourceforge.net Wed Jul 9 14:33:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 06:33:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-768419 ] Subtle bug in os.path.realpath on Cygwin Message-ID: Bugs item #768419, was opened at 2003-07-09 14:38 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768419&group_id=5470 Category: Python Library Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: Subtle bug in os.path.realpath on Cygwin Initial Comment: Cygwin allows mounting directories within other mount points. This can cause os.path.realpath to expand some symlinks that it shouldn't. For example: $ cd / $ mkdir X $ mkdir X/Y $ ln -s X Z $ mount C:/ /Z/Y $ ls Z/Y [...contents of C:\...] $ ls X/Y [empty directory] $ python -c "import os; print os.path.realpath('Z/Y')" /X/Y [bad because /X/Y is empty yet the original Z/Y has files] In Cygwin, the correct answer would be either 'C:\' or '/cygdrive/c/'. Conceivably this problem can happen in UNIces other than Cygwin. It would be rather annoying to fix, because it would require looking at the mount table. But I thought I would mention it anyway... ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2003-07-09 15:33 Message: Logged In: YES user_id=43607 I'd think this is rather a Cygwin bug than a Python bug. Before the mount, /X/Y and /Z/Y refer to the same directory, and on Unix they have the same device/inode combination. And that combination is the all-important factor when doing a mount on that directory. If you do this on Unix (I used an NFS mount instead of the mount shown in the report), both /X/Y and /Z/Y contain the mounted directory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768419&group_id=5470 From noreply@sourceforge.net Wed Jul 9 14:49:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 06:49:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13: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=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Wed Jul 9 15:11:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 07:11:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-768481 ] Column Number is not visible in MacOSX Message-ID: Bugs item #768481, was opened at 2003-07-09 14: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=768481&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: Column Number is not visible in MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, the column number, which should appear in the lower right-hand corner, is not visible. It is obscured by the Aqua resize widget which is always anchored to the lower right-hand corner. The column number becomes briefly visible when the IDLE window is resized, only to be obscured again when the final redraw is performed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768481&group_id=5470 From noreply@sourceforge.net Wed Jul 9 15:13:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 07:13:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-768391 ] hardcoded python paths Message-ID: Bugs item #768391, was opened at 2003-07-09 11:39 Message generated for change (Settings changed) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768391&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: hardcoded python paths Initial Comment: I tried to use the new version of idle that is now integrated into 2.3b2, but I got an error when I tried to run /usr/local/lib/python2.3/idlelib/idle: % /usr/local/lib/python2.3/idlelib/idle Traceback (most recent call last): File "./idle", line 8, in ? import PyShell File "./PyShell.py", line 19, in ? from Tkinter import * File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 35, in ? import _tkinter # If this fails your Python may not be configured for Tk ImportError: No module named _tkinter I'm using python2.3b2 on MacOSX 10.2.6, compiled from source with standard options. Apparently the builtin 2.2 version of Python is being used, even though $PYTHONHOME is not set (according to the manpages, this should make it default to /usr/local, and not /usr as seems to be the case). This is due to the fact that this executable script contains a shebang declaration with a hardcoded python path: % head -1 /usr/local/lib/python2.3/idlelib/idle #!/usr/bin/python This should be replaced by the standard shebang declaration: #! /usr/bin/env python I checked to see if there were any other *.py files in /usr/local/lib/python2.3 suffering from similar problems, and found the following files to be affected: /usr/local/lib/python2.3/cgi.py: #! /usr/local/bin/python /usr/local/lib/python2.3/test/test_bz2.py: #!/usr/bin/python /usr/local/lib/python2.3/test/test_largefile.py: #!python /usr/local/lib/python2.3/test/test_optparse.py: #!/usr/bin/python The files /usr/local/bin/idle, /usr/local/bin/pydoc and /usr/local/bin/pycolor also have a hardcoded python path: % head -1 idle pycolor pydoc ==> idle <== #!/usr/local/bin/python ==> pycolor <== #!/usr/local/bin/python ==> pydoc <== #!/usr/local/bin/python These should similarly be changed to #! /usr/bin/env python ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768391&group_id=5470 From noreply@sourceforge.net Wed Jul 9 15:14:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 07:14:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-768481 ] Column Number is not visible in MacOSX Message-ID: Bugs item #768481, was opened at 2003-07-09 14:11 Message generated for change (Settings changed) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768481&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: Column Number is not visible in MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, the column number, which should appear in the lower right-hand corner, is not visible. It is obscured by the Aqua resize widget which is always anchored to the lower right-hand corner. The column number becomes briefly visible when the IDLE window is resized, only to be obscured again when the final redraw is performed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768481&group_id=5470 From noreply@sourceforge.net Wed Jul 9 15:14:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 07:14:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Settings changed) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Wed Jul 9 16:09:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 08:09:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-722763 ] weakref: proxy_print and proxy_repr incons. Message-ID: Bugs item #722763, was opened at 2003-04-16 17:49 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=722763&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weakref: proxy_print and proxy_repr incons. Initial Comment: For weakref.proxy, the behavior of proxy_print() in "cooked" mode is inconsistent with the behavior of proxy_repr(). "cooked" mode printing is used when a value is displayed at the command line. Sample session: >>> class C: pass ... >>> from weakref import proxy >>> a = C() >>> p = proxy(a) >>> p <__main__.C instance at 0x400e864c> >>> print repr(p) >>> The output should be the same in both cases. (My suggestion: get rid of proxy_print. Might be a tad slower in extreme cases, but gets this right with ease. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=722763&group_id=5470 From noreply@sourceforge.net Wed Jul 9 16:23:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 08:23:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-767228 ] Pickle (cPickle) __getinitargs__ problem in 2.3b2 ? Message-ID: Bugs item #767228, was opened at 2003-07-07 17:18 Message generated for change (Comment added) made by gmirai You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767228&group_id=5470 Category: Python Library Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Gregor Mirai (gmirai) Assigned to: Jeremy Hylton (jhylton) Summary: Pickle (cPickle) __getinitargs__ problem in 2.3b2 ? Initial Comment: The following code works correctly with 2.3b1 (on MacOS X), but it throws KeyError: __getinitargs__ with 2.3b2 : -------------------------------------------- #!/usr/bin/env python import cPickle as c class Style: def __init__(self): self.d = {} def __setitem__(self, key, value): self.d["d_"+key]=value def __getattr__(self, key): if key.startswith("d_"): return self.d[key] else: return self.__dict__[key] s = Style() s["A"] = "B" print s.d_A print c.dumps(s) -------------------------------------------- The problem shows with any class that should override __getattr__ attribute. So it seems that pickle is broken in the new release ? ---------------------------------------------------------------------- >Comment By: Gregor Mirai (gmirai) Date: 2003-07-09 15:23 Message: Logged In: YES user_id=817617 Correct __getattr__ method should be: def __getattr__(self, key): if key.startswith("d_"): return self.d[key] elif key in self.__dict__: return self.__dict__[key] else: raise AttributeError Tnx Jeremy. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-08 12:21 Message: Logged In: YES user_id=31392 This isn't a bug after all. cPickle and pickle now produce the same results, which is a KeyError. The __getattr__() method in the example code is incorrect, because it raises KeyError for missing attributes instead of AttributeError. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2003-07-07 19:14 Message: Logged In: YES user_id=31392 I probably broke something in change that catches only specific exceptions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767228&group_id=5470 From noreply@sourceforge.net Wed Jul 9 17:39:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 09:39:16 -0700 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 10:58 Message generated for change (Comment added) made by gvanrossum 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: Guido van Rossum (gvanrossum) Date: 2003-07-09 12: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 23: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 11: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 23: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 23: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@sourceforge.net Wed Jul 9 18:13:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 10:13:55 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-748201 ] time.strptime() should display format and date on error Message-ID: Feature Requests item #748201, was opened at 2003-06-03 07:14 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=748201&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Guettler (guettli) Assigned to: Brett Cannon (bcannon) Summary: time.strptime() should display format and date on error Initial Comment: Hi! It would be very nice if the ValueError of time.strptime() would display the format and the date if there is a mismatch. Up to now (python 2.2.2) the Error looks like this: ValueError: format mismatch It would be nice if it would look like this: format mismatch: str=2002.12.24 format=%Y-%m-%d thomas ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-09 10:13 Message: Logged In: YES user_id=357491 I will see what I can do. I am not going to touch this, though, until after 2.3 is out since I don't want to risk breaking any code. Besides, strptime is going to get a slight overhaul after 2.3 comes out to clean it up and make it leaner. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 04:08 Message: Logged In: YES user_id=89016 Maybe time.strptime() should use a subclass of ValueError, with proper attributes. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-27 23:17 Message: Logged In: YES user_id=80475 Helpful, informative error messages are certainly a step in the right direction. Referrring to Brett for implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=748201&group_id=5470 From noreply@sourceforge.net Wed Jul 9 18:15:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 10:15:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 05:35 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-09 10:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 22:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 19:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 10:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 08:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Wed Jul 9 19:03:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 11:03:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-763708 ] Failures in test_macostools Message-ID: Bugs item #763708, was opened at 2003-06-30 23:54 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-09 11:03 Message: Logged In: YES user_id=357491 OK, so the problem seems to be coming from Mac/Modules/file/ _Filemodule.c and the File_FSGetResourceForkName function (printing the result just prints "ERROR"). The online docs for FSGetResourceForkName (which is pretty much all that is called in that function) can be found at http://developer.apple.com/ documentation/Carbon/Reference/File_Manager/file_manager/ function_group_20.html#//apple_ref/c/func/ FSGetResourceForkName . Now it looks like the error is an OS X error and has nothing to do with Python. The error (-1402) means that the fork name is syntactically invalid. I don't see how this can mean anything, though, since FSGetResourceForkName's only argument is a pointer to store the result of the call into. The only thing I can think of that might be causing this error from Python's side is that a resource fork does not exist when the call is made. But this is just a guess so I could be wrong. Jack, I am going to be gone from July 13 until July 21, so if you need any debugging info from me before 2.3 final goes out I am afraid it will have to happen soon. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:42 Message: Logged In: YES user_id=357491 OK, Jack, here is your info: - 10.2.6 - Python 2.3b2+ straight from CVS (only way to code =) - HFS+ I believe (Finder says my HD is Mac OS Extended) Ran the test from my CVS tree with my installed version of Python 2.3b2+ (I can't do anything the standard way). I just ran it with the installed copy from the installed test directory and got the errors. I also just ran it with the compiled copy but not installed Python executable in my CVS tree and once again got the error. I noticed this came up, for me at least, when I was checking a patch for posixpath.py (which was applied to CVS). I checked the code, though, and didn't find a problem where anything changed to posixpath.py would affect it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 04:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply@sourceforge.net Wed Jul 9 19:07:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 11:07:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-767645 ] incorrect os.path.supports_unicode_filenames Message-ID: Bugs item #767645, was opened at 2003-07-08 02:42 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect os.path.supports_unicode_filenames Initial Comment: At least on OSX, unicode file names are pretty much fully supported, yet os.path.supports_unicode_filenames is False (it comes from posixpath.py, which hard codes it). What would be a proper way to detect unicode filename support for posix platforms? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-09 11:07 Message: Logged In: YES user_id=357491 What happens if you try to create a file using Unicode names? Could a test get the temp directory for the platform, write a file with Unicode in it, and then check for an error? Or if it always succeeds, write it, and then see if the results match? In other words, does writing Unicode to an ASCII file system ever lead to a mangling of the name? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 From noreply@sourceforge.net Wed Jul 9 19:24:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 11:24:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 12:04 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Later Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Guido van Rossum (gvanrossum) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-09 14:24 Message: Logged In: YES user_id=6380 I've asked on python-dev for help with this, as I expect I won't have time for it before July 17 (cut-off date for 2.3c1). Feel free to assign this to yourself if you want to grab it. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-22 14:33 Message: Logged In: YES user_id=261020 I tested the 301 behaviour of MSIE 5.00 on wine, and Mozilla Firebird 0.6. Both redirect POST to GET (without asking for user confirmation) on a 301 redirect, as expected, so it's probably justified to follow through with the 301 changes we discussed (summarised in my last message, along with a couple of related changes; item 1 has already been done). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 08:45 Message: Logged In: YES user_id=261020 Sorry for all these tiny updates. Summary of what remains to be done: 1. Apply Guido's patch for urllib.py: guido.txt. The docs are already correct. 2. 301 in response to POST is still not redirected in urllib2. urllib2.py.patch3 fixes that (note patch3, not patch2). It also removes my Request.get_method method (which now seems like overkill, as well as breaking the URL scheme-independence of Request). Also fixes an exception message. 3. liburllib2.tex.patch2 updates the docs to reflect the changes in urllib2.py.patch3, rephrases a note and adds a missing method description. 4. liburllib.tex.patch2: trivial rewording of docs for clarity. 5. Backport above changes to 2.2 bugfix branch. Jeremy in CVS: > The latest changes to the redirect handler couldn't possibly have been > tested, because they did not compute a newurl and failed with a > NameError. The __name__ == "__main__": block has a test for > redirects. Ah. The tests are preceeded by a warning about only working from a particular set of hosts: I mis-remembered, thinking that applied to *all* the tests. Sorry. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 20:14 Message: Logged In: YES user_id=261020 OK, I can't test IE, because Windows doesn't have a proper loopback adapter, and my Windows machine is disconnected. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 08:46 Message: Logged In: YES user_id=261020 Another test result on browser behaviour with 301 response to POST: lynx 2.8.4rel.1: offers user a choice between POST, GET and cancel Still haven't checked IE. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-07 10:21 Message: Logged In: YES user_id=261020 About 301: I tested Mozilla 1.0.0 and Konqueror 3.1.0 and they both redirect POST to GET without asking for confirmation. Ronald Tschalar tells me he tested Mozilla 1.1 and Netscape 4.7, and got the same result. So, all is as we had thought there (haven't checked IE, though). Side note: After reading another comment of Ronald's (he's the author of the HTTPClient java library), I realise that it would be a good idea to have urllib / urllib2 cache the results of 301 redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC says SHOULD happen. I'll file a separate bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-06 16:18 Message: Logged In: YES user_id=261020 What, a different urllib2 bug than the two that I uploaded patches for on 2003-04-27? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-04 20:27 Message: Logged In: YES user_id=6380 Note that Jeremy found a bug in what's currently checked in for urllib2.py. I'll try to sort this out coming Friday. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-26 21:33 Message: Logged In: YES user_id=261020 Damn this SF bug system. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-26 21:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-26 21:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-26 13:21 Message: Logged In: YES user_id=6380 Blech! Reopening. I just stumbled upon the relevant part of RFC 2616, and it suggests to me the following rules when the original request was a POST. I should have made the time for this earlier, but I simply didn't have time. :-( Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Summary: - 307 means repeat the POST to the new URL *after user confirmation* - 303 means do a GET to the new URL - 301 means repeat the POST to the new URL *after user confirmation*, *but* old agents often do a GET instead - 302 may be treated the same as 303 (i.e. GET the new URL) for compatibility with existing practice This suggests to me that *no* automatic repeat of POST requests should ever be done, and that in the case of a 302 or 303 response, a POST should be replaced by a GET; this may also be done for a 301 response -- even though the standard calls that an error, it admits that it is done by old clients. But the new code in urllib.py doesn't seem to do that: it treats 301, 302 and 303 all the same, doing a POST if the original request was a POST (POST is determined by 'data is not None'). And it doesn't redirect on a 307 at all, even though it should do that if the original request was GET. The updated documentation describes the desired behavior for 301,302,303. I think the desired behavior can be obtained by always omitting the data argument in the call to self.open(newurl) in redirect_internal(). Then a handler for 307 could be handled that raises an error if the original request was a POST, and redirects otherwise. I'm attaching a suggested patch to urllib.py (guido.txt). It appears urllib2.py was patched correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-25 04:21 Message: Logged In: YES user_id=80475 Backported to 2.2.3. Closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 11:49 Message: Logged In: YES user_id=6380 Yes, I think that would be a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 11:34 Message: Logged In: YES user_id=80475 Committed as: Lib/urllib.py 1.157 Lib/urllib2.py 1.39 Doc/lib/liburllib.tex 1.47 Doc/lib/liburllib2.tex 1.7 Guido, would you like this backported to 2.2.3? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-20 16:44 Message: Logged In: YES user_id=261020 Just noticed that I forgot to upload one of the doc patches on 2003-03-05. Here it is. The patches that need to be applied are the three I uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch and liburllib2.tex.patch), and the liburllib.tex.patch I just uploaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 16:35 Message: Logged In: YES user_id=6380 I think this is the right thing to do. Can you check it in? (There are several files -- urllib, urllib2, and its docs). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-16 16:27 Message: Logged In: YES user_id=80475 Do you have time to take this one back? My head starts to explode when researching whether this is the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 15:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 16:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 11:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 11:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-09 21:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 17:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 14:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 12:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 13:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 15:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-19 20:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 17:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 17:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 17:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 11:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 14:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 12:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-28 20:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 12:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Wed Jul 9 19:30:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 11:30:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 14:35 Message generated for change (Comment added) made by towi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- >Comment By: Torsten Will (towi) Date: 2003-07-09 20:30 Message: Logged In: YES user_id=269193 sorry, problem! hard drive scambled. i have to re-install python anyway. i will see if the test fails again, and then i try to apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 19:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 07:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 04:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 19:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 17:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Wed Jul 9 19:36:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 11:36:58 -0700 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 (Tracker Item Submitted) made by Item Submitter 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768649&group_id=5470 From noreply@sourceforge.net Wed Jul 9 20:30:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 12:30:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-764560 ] python treats IRIX64 and IRIX as different, but they are the Message-ID: Bugs item #764560, was opened at 2003-07-02 14:38 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764560&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gordon Lack (gmlack) >Assigned to: Martin v. Löwis (loewis) Summary: python treats IRIX64 and IRIX as different, but they are the Initial Comment: Related to bug 216255 (116255?), but this goes deeper, as it refers to the *running* of python rather than just its building. If I build python on an Irix6.5 system (that is new/large) the tag "irix646" is used in the build/temp.* directory (and Lib/plat-*). This has several effects: a) the plat-irix6 directory from the standard distribution is ignored. b) running the tests on an IRIX system after compiling on an IRIX64 one causes it to rebuild everything, as it will look for temp.irix-6.5-2.2 and lib.irix-6.5-2.2 in build/ rather than the temp.irix64-6.5-2.2 and lib.irix64-6.5-2.2 which were actually built. c) running the same executable on a smaller system (a single installation, NFS mounted onto a large number of systems, for which "uname -s" returns IRIX, not IRIX64) will cause it to fail to find the </python2.2/Lib/plat-irix646 directory. (This might also affect 3rd party module installation?). IRIX and IRIX64 are the same when you build n32 binaries (which is what is built by default). Python should treat them the same. It should be possible to *configure* this OS tag at configure time (which would avoid this problem). Also, installing the "plat-irix646" directories under <> rather than <> would remove the need for such a tag in the installed files. ---------------------------------------------------------------------- Comment By: Gordon Lack (gmlack) Date: 2003-07-09 15:14 Message: Logged In: YES user_id=88015 Ok - to fix this *particular* part of the problem turns out to be simple. (I had tried setting MACHDEP in my environment, but that fails as, if MACHDEP is set, then the configure script does not set ac_sys_system and ac_sys_release so tests on these fail to get done). So, attached is the patch which equates the two. NOTE: There are other build problems. The SGI C linker (and OSF1) uses -rpath not -R, and the extension buuilding scripts don't knwo how to handle this...but I suppose these would be for a different bug report. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:32 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=105470&aid=764560&group_id=5470 From noreply@sourceforge.net Wed Jul 9 21:05:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 13:05:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-768698 ] Odd behavior in the file object Message-ID: Bugs item #768698, was opened at 2003-07-09 20: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=768698&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Nemeth (davidnemeth) Assigned to: Nobody/Anonymous (nobody) Summary: Odd behavior in the file object Initial Comment: Hello, I was using Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 to write a file to parse a text file. The file was divided in two parts, so I wrote something like this: file = open("foobar" ,"r") for line in file: #read a few lines break for line in file: read rest of lines A chunk of the middle part of the file ends up missing. Oddly, it's not the section just after the first few lines are read. I've attached an example script and data file which shows this problem on my system (Windows 2000). The workaround I'm using (which works) is : file = open("foobar","r") while 1: line = file.readline() if line is what I want: break for line in file: do stuff Which seems to work ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768698&group_id=5470 From noreply@sourceforge.net Wed Jul 9 23:29:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 15:29:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-682648 ] urllib2 HTTPDigestAuthHandler misnamed class attr Message-ID: Bugs item #682648, was opened at 2003-02-07 19:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=682648&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: steve steiner (ssteiner) >Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 HTTPDigestAuthHandler misnamed class attr Initial Comment: The class attribute 'header' should be named 'auth_header' as it is in HTTPBasicAuthHandler. Same is true of ProxyDigestAuthHandler. These classes throw an AttributeError (shown below for HTTPDigestAuthHandler: AttributeError: HTTPDigestAuthHandler instance has no attribute 'auth_header' ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-09 18:29 Message: Logged In: YES user_id=33168 Jeremy, do you have time to look at this? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-09 21:59 Message: Logged In: YES user_id=33168 Sure looks right to me (ie, changing header to auth_header). Can you supply tests? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=682648&group_id=5470 From noreply@sourceforge.net Thu Jul 10 04:20:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 20:20:29 -0700 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 14:36 Message generated for change (Comment added) made by nnorwitz 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: Neal Norwitz (nnorwitz) Date: 2003-07-09 23: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@sourceforge.net Thu Jul 10 04:27:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 20:27:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-768857 ] file readline() mishandles \032 char on Windows Message-ID: Bugs item #768857, was opened at 2003-07-09 23: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=768857&group_id=5470 Category: Windows Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Mark Bucciarelli (mbucc) Assigned to: Tim Peters (tim_one) Summary: file readline() mishandles \032 char on Windows Initial Comment: The following snippet behaves differently on Windows (2.2.2) and Linux (2.2.1). >>>s = 'ab\032cd' >>>f = file('test', 'w') >>>f.write(s+'\n') >>>f.close() >>>f = file('test') >>>f.readline() Linux returns: 'ab\x1a\cd\n' Windows returns: 'ab' \032 is ascii substitute and also ^z according to this page (http://francis.courtois.free.fr/jc1/serial/Resources/ASCII.html). Thank you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768857&group_id=5470 From noreply@sourceforge.net Thu Jul 10 04:35:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 20:35:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-768859 ] odd behavior of try-break-finally on IDLE Message-ID: Bugs item #768859, was opened at 2003-07-10 12:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768859&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: odd behavior of try-break-finally on IDLE Initial Comment: I've found an odd behavior of try-break-finally expression inside a function on IDLE. See the code below. Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0b2 >>> try: break finally: print "finally" SyntaxError: 'break' outside loop As you expect, you get SyntaxError. However, if you wrap them in a function, >>> def foo(): try: break finally: print "finally" after pressing a few times, IDLE exits suddenly ( and silently). If you do the same thing from the command line, there's no problem. You get the SyntaxError in either case. On an older IDLE, the error messages are much more verbose. Although I've tested this on a localized(Japanese enhanced) Python, I guess the result will be the same. Python 2.2.3 (SJIS enhanced) (#42, Jun 8 2003, 01:46:45) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> def foo(): try: break finally: print "finally" Exception in Tkinter callback Traceback (most recent call last): File "c:\Python22jp\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\python22jp\Tools\idle\PyShell.py", line 595, in enter_callback self.runit() File "C:\python22jp\Tools\idle\PyShell.py", line 614, in runit more = self.interp.runsource(line) File "C:\python22jp\Tools\idle\PyShell.py", line 192, in runsource return InteractiveInterpreter.runsource(self, source, filename) File "c:\Python22jp\lib\code.py", line 79, in runsource self.showsyntaxerror(filename) File "C:\python22jp\Tools\idle\PyShell.py", line 219, in showsyntaxerror pos = "iomark linestart + %d lines + %d chars" % (lineno-1, TypeError: unsupported operand type(s) for - : 'NoneType' and 'int' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768859&group_id=5470 From noreply@sourceforge.net Thu Jul 10 05:08:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 21:08:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-743692 ] test_socketserver: Fatal error: Invalid thread state Message-ID: Bugs item #743692, was opened at 2003-05-26 10:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743692&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Mark Hammond (mhammond) Summary: test_socketserver: Fatal error: Invalid thread state Initial Comment: Mark, I believe this started happening on Solaris 8 (only AFAIK) after some of your thread changes. Do you have access to a Solaris 8 box? I can try to debug if you give me some ideas. This is happening on the snake farm. Actually, we have a Sol8 box here. I can try to fire it up and see if the problem exists on that box. If so, I can give you access. When running test_socketserver, some way through the test there's the fatal error. Fatal Python error: Invalid thread state for this thread Let me know what more info I can provide. Sorry, short on ideas/time, just wanted to get this documented. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-10 00:08 Message: Logged In: YES user_id=33168 Doesn't seem real helpful. I'll see if I can do more on this. #0 PyThreadState_Swap (new=0x2b1160) at Python/pystate.c:274 #1 PyEval_RestoreThread (tstate=0x2b1160) at Python/ceval.c:391 #2 floatsleep (secs=0) at Modules/timemodule.c:831 #3 time_sleep (self=0x0, args=0x2b3968) at Modules/timemodule.c:208 #4 PyCFunction_Call (func=0x2bd938, arg=0x2b3968, kw=0x0) at Objects/methodobject.c:73 #5 call_function (pp_stack=0xdf142f04, oparg=1) at Python/ceval.c:3439 #6 eval_frame (f=0x2890c8) at Python/ceval.c:2116 ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-08 00:39 Message: Logged In: YES user_id=14198 I don't have access to a sol8 box, nor would I really know what to do when I got there :) Any chance of a stack-trace? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743692&group_id=5470 From noreply@sourceforge.net Thu Jul 10 05:25:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 21:25:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-743692 ] test_socketserver: Fatal error: Invalid thread state Message-ID: Bugs item #743692, was opened at 2003-05-26 10:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743692&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Mark Hammond (mhammond) Summary: test_socketserver: Fatal error: Invalid thread state Initial Comment: Mark, I believe this started happening on Solaris 8 (only AFAIK) after some of your thread changes. Do you have access to a Solaris 8 box? I can try to debug if you give me some ideas. This is happening on the snake farm. Actually, we have a Sol8 box here. I can try to fire it up and see if the problem exists on that box. If so, I can give you access. When running test_socketserver, some way through the test there's the fatal error. Fatal Python error: Invalid thread state for this thread Let me know what more info I can provide. Sorry, short on ideas/time, just wanted to get this documented. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-10 00:25 Message: Logged In: YES user_id=33168 I changed the DELAY in the test to be zero. The test fails, but it's interesting that it also hangs in lock_PyThread_acquire_lock (line 63): Lib/threading.py (195): wait Lib/threading.py (468): join Lib/threading.py (564): __exitfunc Lib/atexit.py (11): _run_exitfuncs In looking at threadmodule.c I notice that most of the time Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS is not used around PyThread_acquire_lock, but it is in lock_PyThread_acquire_lock. I'm not sure all of these are safe. Here's some more detail on the Sun: test_socketserver ADDR = ('localhost', 17231) CLASS = SocketServer.ForkingTCPServer server created thread: creating server server running thread: serving three times test client 0 Fatal Python error: Invalid thread state for this thread ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-10 00:08 Message: Logged In: YES user_id=33168 Doesn't seem real helpful. I'll see if I can do more on this. #0 PyThreadState_Swap (new=0x2b1160) at Python/pystate.c:274 #1 PyEval_RestoreThread (tstate=0x2b1160) at Python/ceval.c:391 #2 floatsleep (secs=0) at Modules/timemodule.c:831 #3 time_sleep (self=0x0, args=0x2b3968) at Modules/timemodule.c:208 #4 PyCFunction_Call (func=0x2bd938, arg=0x2b3968, kw=0x0) at Objects/methodobject.c:73 #5 call_function (pp_stack=0xdf142f04, oparg=1) at Python/ceval.c:3439 #6 eval_frame (f=0x2890c8) at Python/ceval.c:2116 ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-08 00:39 Message: Logged In: YES user_id=14198 I don't have access to a sol8 box, nor would I really know what to do when I got there :) Any chance of a stack-trace? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743692&group_id=5470 From noreply@sourceforge.net Thu Jul 10 05:37:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 21:37:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 07:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 23:37 Message: Logged In: YES user_id=80475 Tonight, test_time also failed for me and then worked on the next pass. Am using WinME and Py2.3b2+. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-09 13:30 Message: Logged In: YES user_id=269193 sorry, problem! hard drive scambled. i have to re-install python anyway. i will see if the test fails again, and then i try to apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 12:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 00:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 21:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 12:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 10:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Thu Jul 10 05:39:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 21:39:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-768859 ] odd behavior of try-break-finally on IDLE Message-ID: Bugs item #768859, was opened at 2003-07-09 22:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768859&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: George Yoshida (quiver) >Assigned to: Kurt B. Kaiser (kbk) Summary: odd behavior of try-break-finally on IDLE Initial Comment: I've found an odd behavior of try-break-finally expression inside a function on IDLE. See the code below. Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0b2 >>> try: break finally: print "finally" SyntaxError: 'break' outside loop As you expect, you get SyntaxError. However, if you wrap them in a function, >>> def foo(): try: break finally: print "finally" after pressing a few times, IDLE exits suddenly ( and silently). If you do the same thing from the command line, there's no problem. You get the SyntaxError in either case. On an older IDLE, the error messages are much more verbose. Although I've tested this on a localized(Japanese enhanced) Python, I guess the result will be the same. Python 2.2.3 (SJIS enhanced) (#42, Jun 8 2003, 01:46:45) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> def foo(): try: break finally: print "finally" Exception in Tkinter callback Traceback (most recent call last): File "c:\Python22jp\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\python22jp\Tools\idle\PyShell.py", line 595, in enter_callback self.runit() File "C:\python22jp\Tools\idle\PyShell.py", line 614, in runit more = self.interp.runsource(line) File "C:\python22jp\Tools\idle\PyShell.py", line 192, in runsource return InteractiveInterpreter.runsource(self, source, filename) File "c:\Python22jp\lib\code.py", line 79, in runsource self.showsyntaxerror(filename) File "C:\python22jp\Tools\idle\PyShell.py", line 219, in showsyntaxerror pos = "iomark linestart + %d lines + %d chars" % (lineno-1, TypeError: unsupported operand type(s) for - : 'NoneType' and 'int' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 23:39 Message: Logged In: YES user_id=80475 Verified that the behavior persists even after the recent 'break' fix for Py2.3b2+. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768859&group_id=5470 From noreply@sourceforge.net Thu Jul 10 06:17:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 22:17:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-768859 ] odd behavior of try-break-finally on IDLE Message-ID: Bugs item #768859, was opened at 2003-07-09 22:35 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768859&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Pending >Resolution: Works For Me Priority: 6 Submitted By: George Yoshida (quiver) Assigned to: Kurt B. Kaiser (kbk) Summary: odd behavior of try-break-finally on IDLE Initial Comment: I've found an odd behavior of try-break-finally expression inside a function on IDLE. See the code below. Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0b2 >>> try: break finally: print "finally" SyntaxError: 'break' outside loop As you expect, you get SyntaxError. However, if you wrap them in a function, >>> def foo(): try: break finally: print "finally" after pressing a few times, IDLE exits suddenly ( and silently). If you do the same thing from the command line, there's no problem. You get the SyntaxError in either case. On an older IDLE, the error messages are much more verbose. Although I've tested this on a localized(Japanese enhanced) Python, I guess the result will be the same. Python 2.2.3 (SJIS enhanced) (#42, Jun 8 2003, 01:46:45) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> def foo(): try: break finally: print "finally" Exception in Tkinter callback Traceback (most recent call last): File "c:\Python22jp\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\python22jp\Tools\idle\PyShell.py", line 595, in enter_callback self.runit() File "C:\python22jp\Tools\idle\PyShell.py", line 614, in runit more = self.interp.runsource(line) File "C:\python22jp\Tools\idle\PyShell.py", line 192, in runsource return InteractiveInterpreter.runsource(self, source, filename) File "c:\Python22jp\lib\code.py", line 79, in runsource self.showsyntaxerror(filename) File "C:\python22jp\Tools\idle\PyShell.py", line 219, in showsyntaxerror pos = "iomark linestart + %d lines + %d chars" % (lineno-1, TypeError: unsupported operand type(s) for - : 'NoneType' and 'int' ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 00:17 Message: Logged In: YES user_id=149084 I have tried the current CVS on both Windows and Linux and do not see the problem since fixing bug # 767794 yesterday. You have to be sure you are running the fixed version of IDLE. On Linux the default will be to run /usr/local/lib/Python2.3/idlelib/PyShell.py. Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0b2 >>> def foo(): try: break finally: print 'break' SyntaxError: 'break' outside loop >>> def bar(): try: continue finally: print 'bar' SyntaxError: 'continue' not properly in loop >>> ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 23:39 Message: Logged In: YES user_id=80475 Verified that the behavior persists even after the recent 'break' fix for Py2.3b2+. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768859&group_id=5470 From noreply@sourceforge.net Thu Jul 10 06:25:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 22:25:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 08:49 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Pending Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 00:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Thu Jul 10 06:35:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 22:35:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-699630 ] Erroneous error message from IDLE Message-ID: Bugs item #699630, was opened at 2003-03-07 16:09 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699630&group_id=5470 Category: IDLE Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Roy Keir (newbieroy) Assigned to: Nobody/Anonymous (nobody) Summary: Erroneous error message from IDLE Initial Comment: I'm a Python beginner (wrote C programs before I needed GUIs) running 2.2.2 on Windows 98SE from the standard download from www.python.org. I first put a frame ObRef 'f' into a .grid() line instead of into the Label() line above it. When I "fixed" it, I put the 'f' in the Label() but forgot to remove it from .grid(). IDLE's error message identified the erroneous line but reported that '-bd' was not allowed. If it had identified '-f' as the culprit that would have saved me a lot of scrambling. A screen-shot of the code and the error message are attached (MS Word .doc format). The offending line is the seventh line in the code screen-shot. Thanks. Sorry if this is a duplicate. I have searched the python.org FAQ and the Source Forge error list without recognizing this problem in any of their titles. Roy Keir rmkeir@earthlink.net ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 00:35 Message: Logged In: YES user_id=149084 Over a month ago I sent a private message to the reporter requesting proper documentation of the problem, including instructions on screen shots, since the files attached are empty. Putting this bug on pending status since there has been no response. ---------------------------------------------------------------------- Comment By: Roy Keir (newbieroy) Date: 2003-03-09 16:44 Message: Logged In: YES user_id=728836 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. :-( ) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-03-09 12:09 Message: Logged In: YES user_id=80475 Sometimes the SF file upload doesn't take. Please re-attach your screen shot. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=699630&group_id=5470 From noreply@sourceforge.net Thu Jul 10 06:38:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 09 Jul 2003 22:38:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-643571 ] Pythonwin : close() on a stdout Message-ID: Bugs item #643571, was opened at 2002-11-25 09:28 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=643571&group_id=5470 Category: IDLE Group: Python 2.2.2 >Status: Pending >Resolution: Wont Fix Priority: 5 Submitted By: Xavier BASSERY (balthus) >Assigned to: Kurt B. Kaiser (kbk) Summary: Pythonwin : close() on a stdout Initial Comment: I need to treat file objects and sys.stdout object as one. So I can write a class that writes likewise in a file or to standard output. The problem came when I called the close() method of an sys.stdout object. I've seen that in Pythonwin, sys.stdout has such a method. This is not the case in the standard python. And calling it causes that : File "C:\Python22\lib\site-packages\Pythonwin\pywin\scintilla\document.py", line 153, in __call__ return apply(getattr(v, self.name), (std, extra)) AttributeError: OnBraceMatch win32ui: Exception in OnNotify() handler I know that the right way to go is to avoid using the close() method. But methinks it's a bug that the method is available in the IDE of pythonwin. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 00:38 Message: Logged In: YES user_id=149084 Closing the stdout is not very helpful, as you will see if you try it in the interactive interpreter. Take a look at IDLE's PyShell.py for a way to use Pseudofiles, this may help you. We don't deal with Pythonwin. ---------------------------------------------------------------------- Comment By: Xavier BASSERY (balthus) Date: 2002-11-25 09:38 Message: Logged In: YES user_id=653276 >> sys.stdout has such a method. >> This is not the case in the standard python I was not completely right here, in console mode there is the close() methode for sys.stdout object. It's not the case in the IDLE ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=643571&group_id=5470 From noreply@sourceforge.net Thu Jul 10 08:58:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 00:58:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 14:35 Message generated for change (Comment added) made by towi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- >Comment By: Torsten Will (towi) Date: 2003-07-10 09:58 Message: Logged In: YES user_id=269193 no, sorry, no success! * re-compiled python, as expected the test failed again. * patch -p0 <../tzset4.diff * made a "make distclean" * ./configure again, looked nice, no chached stuff. * make * make test >>> failed again !!! anything i could check to help? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-10 06:37 Message: Logged In: YES user_id=80475 Tonight, test_time also failed for me and then worked on the next pass. Am using WinME and Py2.3b2+. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-09 20:30 Message: Logged In: YES user_id=269193 sorry, problem! hard drive scambled. i have to re-install python anyway. i will see if the test fails again, and then i try to apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 19:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 07:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 04:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 19:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 17:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Thu Jul 10 11:27:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 03:27:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-769023 ] No IPv6 support in windows binary Message-ID: Bugs item #769023, was opened at 2003-07-10 12:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769023&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Bergstrøm (andreasb) Assigned to: Tim Peters (tim_one) Summary: No IPv6 support in windows binary Initial Comment: I tried Python 2.2.3 on a Windows XP box with IPv6 enabled, but quickly found out that the socket module under windows was without IPv6 support whatsoever. Things such as socket.AF_INET6 was missing. Is this intentionally or a bug? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769023&group_id=5470 From noreply@sourceforge.net Thu Jul 10 14:30:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 06:30:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-682648 ] urllib2 HTTPDigestAuthHandler misnamed class attr Message-ID: Bugs item #682648, was opened at 2003-02-08 00:05 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=682648&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: steve steiner (ssteiner) Assigned to: Jeremy Hylton (jhylton) Summary: urllib2 HTTPDigestAuthHandler misnamed class attr Initial Comment: The class attribute 'header' should be named 'auth_header' as it is in HTTPBasicAuthHandler. Same is true of ProxyDigestAuthHandler. These classes throw an AttributeError (shown below for HTTPDigestAuthHandler: AttributeError: HTTPDigestAuthHandler instance has no attribute 'auth_header' ---------------------------------------------------------------------- >Comment By: Jeremy Hylton (jhylton) Date: 2003-07-10 13:30 Message: Logged In: YES user_id=31392 Fixed in rev 1.52 of urllib2.py. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-09 22:29 Message: Logged In: YES user_id=33168 Jeremy, do you have time to look at this? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-10 02:59 Message: Logged In: YES user_id=33168 Sure looks right to me (ie, changing header to auth_header). Can you supply tests? Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=682648&group_id=5470 From noreply@sourceforge.net Thu Jul 10 14:52:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 06:52:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Comment added) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 13:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 05:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Thu Jul 10 15:03:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 07:03:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-768857 ] file readline() mishandles \032 char on Windows Message-ID: Bugs item #768857, was opened at 2003-07-09 23:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768857&group_id=5470 Category: Windows >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mark Bucciarelli (mbucc) Assigned to: Tim Peters (tim_one) Summary: file readline() mishandles \032 char on Windows Initial Comment: The following snippet behaves differently on Windows (2.2.2) and Linux (2.2.1). >>>s = 'ab\032cd' >>>f = file('test', 'w') >>>f.write(s+'\n') >>>f.close() >>>f = file('test') >>>f.readline() Linux returns: 'ab\x1a\cd\n' Windows returns: 'ab' \032 is ascii substitute and also ^z according to this page (http://francis.courtois.free.fr/jc1/serial/Resources/ASCII.html). Thank you. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-10 10:03 Message: Logged In: YES user_id=31435 If you want consistent cross-platform behavior when reading or writing binary data, you have to open files in binary mode. That is, do not do f = file('test', 'w') or f = file('test') Instead do f = file('test', 'wb') and f = file('test', 'rb') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768857&group_id=5470 From noreply@sourceforge.net Thu Jul 10 15:04:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 07:04:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-769023 ] No IPv6 support in windows binary Message-ID: Bugs item #769023, was opened at 2003-07-10 06:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769023&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andreas Bergstrøm (andreasb) >Assigned to: Nobody/Anonymous (nobody) Summary: No IPv6 support in windows binary Initial Comment: I tried Python 2.2.3 on a Windows XP box with IPv6 enabled, but quickly found out that the socket module under windows was without IPv6 support whatsoever. Things such as socket.AF_INET6 was missing. Is this intentionally or a bug? ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-10 10:04 Message: Logged In: YES user_id=31435 Unassigned (I don't anything about IPv6). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769023&group_id=5470 From noreply@sourceforge.net Thu Jul 10 15:33:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 07:33:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-768857 ] file readline() mishandles \032 char on Windows Message-ID: Bugs item #768857, was opened at 2003-07-09 23:27 Message generated for change (Comment added) made by mbucc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768857&group_id=5470 Category: Windows Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Mark Bucciarelli (mbucc) Assigned to: Tim Peters (tim_one) Summary: file readline() mishandles \032 char on Windows Initial Comment: The following snippet behaves differently on Windows (2.2.2) and Linux (2.2.1). >>>s = 'ab\032cd' >>>f = file('test', 'w') >>>f.write(s+'\n') >>>f.close() >>>f = file('test') >>>f.readline() Linux returns: 'ab\x1a\cd\n' Windows returns: 'ab' \032 is ascii substitute and also ^z according to this page (http://francis.courtois.free.fr/jc1/serial/Resources/ASCII.html). Thank you. ---------------------------------------------------------------------- >Comment By: Mark Bucciarelli (mbucc) Date: 2003-07-10 10:33 Message: Logged In: YES user_id=35056 Why do you say chr(26) is binary data? It's an ASCII char. Aren't all ASCII characters text? I just built a unit test and all other ascii characters work as expected. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-10 10:03 Message: Logged In: YES user_id=31435 If you want consistent cross-platform behavior when reading or writing binary data, you have to open files in binary mode. That is, do not do f = file('test', 'w') or f = file('test') Instead do f = file('test', 'wb') and f = file('test', 'rb') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768857&group_id=5470 From noreply@sourceforge.net Thu Jul 10 15:46:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 07:46:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-768857 ] file readline() mishandles \032 char on Windows Message-ID: Bugs item #768857, was opened at 2003-07-09 23:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768857&group_id=5470 Category: Windows Group: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Mark Bucciarelli (mbucc) Assigned to: Tim Peters (tim_one) Summary: file readline() mishandles \032 char on Windows Initial Comment: The following snippet behaves differently on Windows (2.2.2) and Linux (2.2.1). >>>s = 'ab\032cd' >>>f = file('test', 'w') >>>f.write(s+'\n') >>>f.close() >>>f = file('test') >>>f.readline() Linux returns: 'ab\x1a\cd\n' Windows returns: 'ab' \032 is ascii substitute and also ^z according to this page (http://francis.courtois.free.fr/jc1/serial/Resources/ASCII.html). Thank you. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-10 10:46 Message: Logged In: YES user_id=31435 Because Python uses C I/O, the C standard's definition of binary data is the relevant definition. If you don't have a copy of the C standard, the "Text and Binary Streams" section of http://www-ccs.ucsd.edu/c/lib_file.html is a good summary. It's correct in stating that the only chars with ord below 32 that C guarantees can be written and read in text-mode files are newline and tab (NL and HT). In particular, on Windows chr(26) in a text mode file is taken as an "end of file" indicator. That's been true since the earliest DOS days, and is fine by the C standard. ---------------------------------------------------------------------- Comment By: Mark Bucciarelli (mbucc) Date: 2003-07-10 10:33 Message: Logged In: YES user_id=35056 Why do you say chr(26) is binary data? It's an ASCII char. Aren't all ASCII characters text? I just built a unit test and all other ascii characters work as expected. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-10 10:03 Message: Logged In: YES user_id=31435 If you want consistent cross-platform behavior when reading or writing binary data, you have to open files in binary mode. That is, do not do f = file('test', 'w') or f = file('test') Instead do f = file('test', 'wb') and f = file('test', 'rb') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768857&group_id=5470 From noreply@sourceforge.net Thu Jul 10 16:09:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 08:09:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-768859 ] odd behavior of try-break-finally on IDLE Message-ID: Bugs item #768859, was opened at 2003-07-09 22:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768859&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed Resolution: Works For Me Priority: 6 Submitted By: George Yoshida (quiver) Assigned to: Kurt B. Kaiser (kbk) Summary: odd behavior of try-break-finally on IDLE Initial Comment: I've found an odd behavior of try-break-finally expression inside a function on IDLE. See the code below. Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0b2 >>> try: break finally: print "finally" SyntaxError: 'break' outside loop As you expect, you get SyntaxError. However, if you wrap them in a function, >>> def foo(): try: break finally: print "finally" after pressing a few times, IDLE exits suddenly ( and silently). If you do the same thing from the command line, there's no problem. You get the SyntaxError in either case. On an older IDLE, the error messages are much more verbose. Although I've tested this on a localized(Japanese enhanced) Python, I guess the result will be the same. Python 2.2.3 (SJIS enhanced) (#42, Jun 8 2003, 01:46:45) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE 0.8 -- press F1 for help >>> def foo(): try: break finally: print "finally" Exception in Tkinter callback Traceback (most recent call last): File "c:\Python22jp\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\python22jp\Tools\idle\PyShell.py", line 595, in enter_callback self.runit() File "C:\python22jp\Tools\idle\PyShell.py", line 614, in runit more = self.interp.runsource(line) File "C:\python22jp\Tools\idle\PyShell.py", line 192, in runsource return InteractiveInterpreter.runsource(self, source, filename) File "c:\Python22jp\lib\code.py", line 79, in runsource self.showsyntaxerror(filename) File "C:\python22jp\Tools\idle\PyShell.py", line 219, in showsyntaxerror pos = "iomark linestart + %d lines + %d chars" % (lineno-1, TypeError: unsupported operand type(s) for - : 'NoneType' and 'int' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-10 10:09 Message: Logged In: YES user_id=80475 Okay, it works fine now. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 00:17 Message: Logged In: YES user_id=149084 I have tried the current CVS on both Windows and Linux and do not see the problem since fixing bug # 767794 yesterday. You have to be sure you are running the fixed version of IDLE. On Linux the default will be to run /usr/local/lib/Python2.3/idlelib/PyShell.py. Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0b2 >>> def foo(): try: break finally: print 'break' SyntaxError: 'break' outside loop >>> def bar(): try: continue finally: print 'bar' SyntaxError: 'continue' not properly in loop >>> ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 23:39 Message: Logged In: YES user_id=80475 Verified that the behavior persists even after the recent 'break' fix for Py2.3b2+. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768859&group_id=5470 From noreply@sourceforge.net Thu Jul 10 16:38:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 08:38:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 07:35 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-10 02:58 Message: Logged In: YES user_id=269193 no, sorry, no success! * re-compiled python, as expected the test failed again. * patch -p0 <../tzset4.diff * made a "make distclean" * ./configure again, looked nice, no chached stuff. * make * make test >>> failed again !!! anything i could check to help? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 23:37 Message: Logged In: YES user_id=80475 Tonight, test_time also failed for me and then worked on the next pass. Am using WinME and Py2.3b2+. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-09 13:30 Message: Logged In: YES user_id=269193 sorry, problem! hard drive scambled. i have to re-install python anyway. i will see if the test fails again, and then i try to apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 12:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 00:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 21:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 12:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 10:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Thu Jul 10 17:30:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 09:30:27 -0700 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 15:58 Message generated for change (Comment added) made by mwh 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: Michael Hudson (mwh) Date: 2003-07-10 17: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 17: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-07-01 04: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 16: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-29 04:10 Message: Logged In: YES user_id=33168 Tim, for 2.3b2 or 2.3.1? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-29 04: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@sourceforge.net Thu Jul 10 17:40:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 09:40:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-755564 ] Tutorial: 4.7.2 Keyword Arguments **name output order wrong Message-ID: Bugs item #755564, was opened at 2003-06-16 16:53 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755564&group_id=5470 Category: Documentation Group: Not a Bug >Status: Closed >Resolution: Works For Me Priority: 3 Submitted By: Jan Mattila (kakkonen) Assigned to: Raymond Hettinger (rhettinger) Summary: Tutorial: 4.7.2 Keyword Arguments **name output order wrong Initial Comment: In the Tutorial at chapter 4.7.2 Keyword Arguments, there is an example about the formal parameter **name. I'm quoting the whole thing, for quick reference: --- begin extract from Tutorial --- def cheeseshop(kind, *arguments, **keywords): print "-- Do you have any", kind, '?' print "-- I'm sorry, we're all out of", kind for arg in arguments: print arg print '-'*40 for kw in keywords.keys(): print kw, ':', keywords[kw] It could be called like this: cheeseshop('Limburger', "It's very runny, sir.", "It's really very, VERY runny, sir.", client='John Cleese', shopkeeper='Michael Palin', sketch='Cheese Shop Sketch') and of course it would print: -- Do you have any Limburger ? -- I'm sorry, we're all out of Limburger It's very runny, sir. It's really very, VERY runny, sir. ---------------------------------------- client : John Cleese shopkeeper : Michael Palin sketch : Cheese Shop Sketch --- end extract from Tutorial --- What it actually prints on my LFS 3.3 (linuxfromscratch) based distribution with Python 2.1.3 is --- begin print out of cheeseshop --- -- Do you have any Limburger ? -- I'm sorry, we're all out of Limburger It's very runny, sir. It's really very, VERY runny, sir. ---------------------------------------- client : John Cleese sketch : Cheese Shop Sketch shopkeeper : Michael Palin --- end print out of cheeseshop --- The problem is that the keywords[kw] list order is garbled. I tried stripping this function of the *arguments formal parameter and I got the same result. I tried different amounts of **keywords in different aphabetical orders. The resulting order does not seem to be random and does not seem to be aplhabetical nor related to the length of the **keywords or anything I could figure out. It's probably not a typo (on my part), because I copied the code straight from the Tutorial page. Now, this is not really a bug in my opinion, so I'm not expecting a fix, but I was just trying to read through the Tutorial and try all the example code and got stuck trying to figure how you could tell the print order of a formal parameter **name -type's name[kw] list. I was thinking, that maybe if someone of class wizard or higher would care to indulge me in the reason for this behaviour I could become enlightened on another aspect of Python. I'm not expecting swift replies, since this is a zero-priority glitch, but someone, somewhere, someday, maybe? No? Okay. Just a thought... So much for trying to make this short. I managed to reproduce the problem on Python 1.5.2 on Red Hat Linux 7.3.2 on linux-i386 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-10 11:40 Message: Logged In: YES user_id=80475 This was already fixed in 2.2.3 and 2.3b2 by adding keys.sort () to the example. ---------------------------------------------------------------------- Comment By: Jan Mattila (kakkonen) Date: 2003-06-17 17:10 Message: Logged In: YES user_id=802538 Right, Can you force the submitter's comments to fall in line with the rest of the comments, instead of getting pushed to the front of the que? This order breaks the chain of comments and, is IMHO more difficult to read. Be that as it may. I read a couple of these bug report thingies and felt that I should propose some text in html format if I wanted anything to go anywhere, without burdening people with genuinely important things to do. I'm attaching a file with the bit of code from the last comment and some explanatory text in html format (please excuse the language). The text is proposed to replace chapter 4.7.2 in the Python 2.1.3 Tutorial at: http://www.python.org/doc/2.1.3/tut/node6.html#SECTION006720000000000000000 N.B. There are two comments in the html, so if none are allowed in the tutorial html, you know what to do with them. -Jan P.S. I realise that putting all of this under the heading "Keyword arguments" is stretching it beyond breaking point. Thus maybe the quickest way would be to just add the text from chapter 5.4 to chapter 4.7.2, something like this: "Note that the keys() method of a dictionary object returns a list of all the keys used in the dictionary, in random order." ---------------------------------------------------------------------- Comment By: Jan Mattila (kakkonen) Date: 2003-06-17 15:04 Message: Logged In: YES user_id=802538 Thanks Christopher, Your reply solved the mystery, but I was unable to find the text you mentioned in the Tutorial at: http://www.python.org/doc/2.1.3/tut/tut.html I tried searching the whole thing, just in case, and the closest I found was this: "The keys() method of a dictionary object returns a list of all the keys used in the dictionary, in random order (if you want it sorted, just apply the sort() method to the list of keys)." But it was in chapter 5.4 Dictionaries, which is quite a way from the mystery at Chapter 4.7.2. I mean the text you quoted? would solve the mystery instantly and even shed light on how to fix it. That is, if it was in the tutorial. My question is: Can you or someone put it there? Additionally it would be nice to either exclude the sorted list from the Tutorial or add a snippet of code for reproducing the list exactly. I think this could do it (although I'm sure someone knows a better way, and that should go into the tutorial): def cheeseshop(kind, *arguments, **keywords): print "-- Do you have any", kind, '?' print "-- I'm sorry, we're all out of", kind for arg in arguments: print arg print '-'*40 info = keywords.items() info.sort() for value in info: print value[0], ':', value[1] -Jan (forgot to sign my last message...) ---------------------------------------------------------------------- Comment By: Christopher Blunck (blunck2) Date: 2003-06-16 22:45 Message: Logged In: YES user_id=531881 Hi Jan- The tutorial points out: Note that the sort() method of the list of keyword argument names is called before printing the contents of the keywords dictionary; if this is not done, the order in which the arguments are printed is undefined. Not sure if a patch is necessary :) -c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=755564&group_id=5470 From noreply@sourceforge.net Thu Jul 10 17:42:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 09:42:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 08:49 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 11:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 08:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 00:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Thu Jul 10 18:11:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 10:11:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 05:35 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-10 10:11 Message: Logged In: YES user_id=357491 Barry says you need to do the following to truly test the patch: - check out the head - make distclean - apply the patch - autoreconf - ./configure --with-pydebug - make test Apparently autoreconf regenerates something for autoconf and that has to be done. Learn something new everyday. Can you give that a shot, Torsten? If that still fails it is going to take some work to figure this one out. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-10 00:58 Message: Logged In: YES user_id=269193 no, sorry, no success! * re-compiled python, as expected the test failed again. * patch -p0 <../tzset4.diff * made a "make distclean" * ./configure again, looked nice, no chached stuff. * make * make test >>> failed again !!! anything i could check to help? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 21:37 Message: Logged In: YES user_id=80475 Tonight, test_time also failed for me and then worked on the next pass. Am using WinME and Py2.3b2+. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-09 11:30 Message: Logged In: YES user_id=269193 sorry, problem! hard drive scambled. i have to re-install python anyway. i will see if the test fails again, and then i try to apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 10:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 22:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 19:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 10:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 08:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Thu Jul 10 20:51:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 12:51:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Comment added) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 16:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 13:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 05:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Thu Jul 10 20:56:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 12:56:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Comment added) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 16:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 13:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 05:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Thu Jul 10 21:47:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 13:47:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-764560 ] python treats IRIX64 and IRIX as different, but they are the Message-ID: Bugs item #764560, was opened at 2003-07-02 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=764560&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gordon Lack (gmlack) Assigned to: Martin v. Löwis (loewis) Summary: python treats IRIX64 and IRIX as different, but they are the Initial Comment: Related to bug 216255 (116255?), but this goes deeper, as it refers to the *running* of python rather than just its building. If I build python on an Irix6.5 system (that is new/large) the tag "irix646" is used in the build/temp.* directory (and Lib/plat-*). This has several effects: a) the plat-irix6 directory from the standard distribution is ignored. b) running the tests on an IRIX system after compiling on an IRIX64 one causes it to rebuild everything, as it will look for temp.irix-6.5-2.2 and lib.irix-6.5-2.2 in build/ rather than the temp.irix64-6.5-2.2 and lib.irix64-6.5-2.2 which were actually built. c) running the same executable on a smaller system (a single installation, NFS mounted onto a large number of systems, for which "uname -s" returns IRIX, not IRIX64) will cause it to fail to find the </python2.2/Lib/plat-irix646 directory. (This might also affect 3rd party module installation?). IRIX and IRIX64 are the same when you build n32 binaries (which is what is built by default). Python should treat them the same. It should be possible to *configure* this OS tag at configure time (which would avoid this problem). Also, installing the "plat-irix646" directories under <> rather than <> would remove the need for such a tag in the installed files. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 22:47 Message: Logged In: YES user_id=21627 There is no attachment. Can you please check the checkbox? ---------------------------------------------------------------------- Comment By: Gordon Lack (gmlack) Date: 2003-07-09 15:14 Message: Logged In: YES user_id=88015 Ok - to fix this *particular* part of the problem turns out to be simple. (I had tried setting MACHDEP in my environment, but that fails as, if MACHDEP is set, then the configure script does not set ac_sys_system and ac_sys_release so tests on these fail to get done). So, attached is the patch which equates the two. NOTE: There are other build problems. The SGI C linker (and OSF1) uses -rpath not -R, and the extension buuilding scripts don't knwo how to handle this...but I suppose these would be for a different bug report. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:32 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=105470&aid=764560&group_id=5470 From noreply@sourceforge.net Thu Jul 10 21:50:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 13:50:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-769023 ] No IPv6 support in windows binary Message-ID: Bugs item #769023, was opened at 2003-07-10 12:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769023&group_id=5470 Category: Windows Group: Python 2.2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Andreas Bergstrøm (andreasb) Assigned to: Nobody/Anonymous (nobody) Summary: No IPv6 support in windows binary Initial Comment: I tried Python 2.2.3 on a Windows XP box with IPv6 enabled, but quickly found out that the socket module under windows was without IPv6 support whatsoever. Things such as socket.AF_INET6 was missing. Is this intentionally or a bug? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 22:50 Message: Logged In: YES user_id=21627 It is intentional. To build software with IPv6 support, you need a recent Windows SDK, e.g. the one that comes with VC7. As Python is going to be built with VC6 for an foreseeable future (including Python 2.3), you won't get IPv6 support. If you really need that feature, you have to rebuild Python from the source. Closing it as "won't fix". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-10 16:04 Message: Logged In: YES user_id=31435 Unassigned (I don't anything about IPv6). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769023&group_id=5470 From noreply@sourceforge.net Thu Jul 10 22:01:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 14:01:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-767645 ] incorrect os.path.supports_unicode_filenames Message-ID: Bugs item #767645, was opened at 2003-07-08 11:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect os.path.supports_unicode_filenames Initial Comment: At least on OSX, unicode file names are pretty much fully supported, yet os.path.supports_unicode_filenames is False (it comes from posixpath.py, which hard codes it). What would be a proper way to detect unicode filename support for posix platforms? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:01 Message: Logged In: YES user_id=21627 On POSIX platforms in general, detecting Unicode file name support is not possible. Posix uses open(2), and only open(2) (alon with creat(2), stat(2) etc) to access files. There is no open_w, or open_utf8, or the like. So file names are byte strings on Posix, and it will stay that way forever. (There is actually also fopen, but that doesn't change the situation at all). On OSX, the situation is somewhat different from POSIX, as you have additional functions to open files (which Python apparently does not use, though), and because OSX specifies that the byte strings have to be NFD UTF-8 (which Python violates AFAICT). The documentation for supports_unicode_filenames says True if arbitrary Unicode strings can be used as file names (within limitations imposed by the file system), and if \function{os.listdir()} returns Unicode strings for a Unicode argument. While the first part is true for OSX, I don't think the second part is. If that ever gets corrected (or verified), no further detection is necessary - just set macpath.supports_unicode_filenames for darwin (assuming you use macpath.py on that system). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 20:07 Message: Logged In: YES user_id=357491 What happens if you try to create a file using Unicode names? Could a test get the temp directory for the platform, write a file with Unicode in it, and then check for an error? Or if it always succeeds, write it, and then see if the results match? In other words, does writing Unicode to an ASCII file system ever lead to a mangling of the name? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 From noreply@sourceforge.net Thu Jul 10 22:05:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 14:05:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-767645 ] incorrect os.path.supports_unicode_filenames Message-ID: Bugs item #767645, was opened at 2003-07-08 11:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect os.path.supports_unicode_filenames Initial Comment: At least on OSX, unicode file names are pretty much fully supported, yet os.path.supports_unicode_filenames is False (it comes from posixpath.py, which hard codes it). What would be a proper way to detect unicode filename support for posix platforms? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:05 Message: Logged In: YES user_id=21627 Brett: As for "writing Unicode to an ASCII file system": there is no such thing. POSIX file systems accept arbitrary bytes, and don't interpret them except by looking at the path separator (in ASCII). So you can put Latin-1, KOI8-r, EUC-JP, UTF-8, gb2312, etc all on a single file system, and people actually do that. The convention is that bytes in file names are interpreted according to the locale's encoding. This is just a convention, and it has some significant flaws. Python follows that convention, meaning that you can use arbitrary Unicode strings in open(), as long as they are supported in the locale's encoding. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:01 Message: Logged In: YES user_id=21627 On POSIX platforms in general, detecting Unicode file name support is not possible. Posix uses open(2), and only open(2) (alon with creat(2), stat(2) etc) to access files. There is no open_w, or open_utf8, or the like. So file names are byte strings on Posix, and it will stay that way forever. (There is actually also fopen, but that doesn't change the situation at all). On OSX, the situation is somewhat different from POSIX, as you have additional functions to open files (which Python apparently does not use, though), and because OSX specifies that the byte strings have to be NFD UTF-8 (which Python violates AFAICT). The documentation for supports_unicode_filenames says True if arbitrary Unicode strings can be used as file names (within limitations imposed by the file system), and if \function{os.listdir()} returns Unicode strings for a Unicode argument. While the first part is true for OSX, I don't think the second part is. If that ever gets corrected (or verified), no further detection is necessary - just set macpath.supports_unicode_filenames for darwin (assuming you use macpath.py on that system). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 20:07 Message: Logged In: YES user_id=357491 What happens if you try to create a file using Unicode names? Could a test get the temp directory for the platform, write a file with Unicode in it, and then check for an error? Or if it always succeeds, write it, and then see if the results match? In other words, does writing Unicode to an ASCII file system ever lead to a mangling of the name? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 From noreply@sourceforge.net Thu Jul 10 22:13:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 14:13:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-767645 ] incorrect os.path.supports_unicode_filenames Message-ID: Bugs item #767645, was opened at 2003-07-08 11:42 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect os.path.supports_unicode_filenames Initial Comment: At least on OSX, unicode file names are pretty much fully supported, yet os.path.supports_unicode_filenames is False (it comes from posixpath.py, which hard codes it). What would be a proper way to detect unicode filename support for posix platforms? ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-10 23:13 Message: Logged In: YES user_id=92689 > On OSX, the situation is somewhat different from POSIX, as > you have additional functions to open files (which Python > apparently does not use, though), and because OSX specifies > that the byte strings have to be NFD UTF-8 (which Python > violates AFAICT). (I'm not 100% sure, but I think the OS corrects that) > True if arbitrary Unicode strings can be used as file names > (within limitations imposed by the file system), and if > \function{os.listdir()} returns Unicode strings for a Unicode > argument. > > While the first part is true for OSX, I don't think the > second part is. It is, we had a long discussion about that back when I implemented that ;-) > If that ever gets corrected (or verified), > no further detection is necessary - just set > macpath.supports_unicode_filenames for darwin (assuming you > use macpath.py on that system). Darwin is a posix platform, so I'll have to add a switch to posixpath.py. Unless you object to that, I will do that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:05 Message: Logged In: YES user_id=21627 Brett: As for "writing Unicode to an ASCII file system": there is no such thing. POSIX file systems accept arbitrary bytes, and don't interpret them except by looking at the path separator (in ASCII). So you can put Latin-1, KOI8-r, EUC-JP, UTF-8, gb2312, etc all on a single file system, and people actually do that. The convention is that bytes in file names are interpreted according to the locale's encoding. This is just a convention, and it has some significant flaws. Python follows that convention, meaning that you can use arbitrary Unicode strings in open(), as long as they are supported in the locale's encoding. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:01 Message: Logged In: YES user_id=21627 On POSIX platforms in general, detecting Unicode file name support is not possible. Posix uses open(2), and only open(2) (alon with creat(2), stat(2) etc) to access files. There is no open_w, or open_utf8, or the like. So file names are byte strings on Posix, and it will stay that way forever. (There is actually also fopen, but that doesn't change the situation at all). On OSX, the situation is somewhat different from POSIX, as you have additional functions to open files (which Python apparently does not use, though), and because OSX specifies that the byte strings have to be NFD UTF-8 (which Python violates AFAICT). The documentation for supports_unicode_filenames says True if arbitrary Unicode strings can be used as file names (within limitations imposed by the file system), and if \function{os.listdir()} returns Unicode strings for a Unicode argument. While the first part is true for OSX, I don't think the second part is. If that ever gets corrected (or verified), no further detection is necessary - just set macpath.supports_unicode_filenames for darwin (assuming you use macpath.py on that system). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 20:07 Message: Logged In: YES user_id=357491 What happens if you try to create a file using Unicode names? Could a test get the temp directory for the platform, write a file with Unicode in it, and then check for an error? Or if it always succeeds, write it, and then see if the results match? In other words, does writing Unicode to an ASCII file system ever lead to a mangling of the name? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 From noreply@sourceforge.net Thu Jul 10 22:29:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 14:29:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 18:04 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Later Priority: 7 Submitted By: John J Lee (jjlee) >Assigned to: Martin v. Löwis (loewis) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-09 20:24 Message: Logged In: YES user_id=6380 I've asked on python-dev for help with this, as I expect I won't have time for it before July 17 (cut-off date for 2.3c1). Feel free to assign this to yourself if you want to grab it. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-22 20:33 Message: Logged In: YES user_id=261020 I tested the 301 behaviour of MSIE 5.00 on wine, and Mozilla Firebird 0.6. Both redirect POST to GET (without asking for user confirmation) on a 301 redirect, as expected, so it's probably justified to follow through with the 301 changes we discussed (summarised in my last message, along with a couple of related changes; item 1 has already been done). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 14:45 Message: Logged In: YES user_id=261020 Sorry for all these tiny updates. Summary of what remains to be done: 1. Apply Guido's patch for urllib.py: guido.txt. The docs are already correct. 2. 301 in response to POST is still not redirected in urllib2. urllib2.py.patch3 fixes that (note patch3, not patch2). It also removes my Request.get_method method (which now seems like overkill, as well as breaking the URL scheme-independence of Request). Also fixes an exception message. 3. liburllib2.tex.patch2 updates the docs to reflect the changes in urllib2.py.patch3, rephrases a note and adds a missing method description. 4. liburllib.tex.patch2: trivial rewording of docs for clarity. 5. Backport above changes to 2.2 bugfix branch. Jeremy in CVS: > The latest changes to the redirect handler couldn't possibly have been > tested, because they did not compute a newurl and failed with a > NameError. The __name__ == "__main__": block has a test for > redirects. Ah. The tests are preceeded by a warning about only working from a particular set of hosts: I mis-remembered, thinking that applied to *all* the tests. Sorry. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 02:14 Message: Logged In: YES user_id=261020 OK, I can't test IE, because Windows doesn't have a proper loopback adapter, and my Windows machine is disconnected. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 14:46 Message: Logged In: YES user_id=261020 Another test result on browser behaviour with 301 response to POST: lynx 2.8.4rel.1: offers user a choice between POST, GET and cancel Still haven't checked IE. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-07 16:21 Message: Logged In: YES user_id=261020 About 301: I tested Mozilla 1.0.0 and Konqueror 3.1.0 and they both redirect POST to GET without asking for confirmation. Ronald Tschalar tells me he tested Mozilla 1.1 and Netscape 4.7, and got the same result. So, all is as we had thought there (haven't checked IE, though). Side note: After reading another comment of Ronald's (he's the author of the HTTPClient java library), I realise that it would be a good idea to have urllib / urllib2 cache the results of 301 redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC says SHOULD happen. I'll file a separate bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-06 22:18 Message: Logged In: YES user_id=261020 What, a different urllib2 bug than the two that I uploaded patches for on 2003-04-27? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 02:27 Message: Logged In: YES user_id=6380 Note that Jeremy found a bug in what's currently checked in for urllib2.py. I'll try to sort this out coming Friday. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 03:33 Message: Logged In: YES user_id=261020 Damn this SF bug system. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 03:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 03:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-26 19:21 Message: Logged In: YES user_id=6380 Blech! Reopening. I just stumbled upon the relevant part of RFC 2616, and it suggests to me the following rules when the original request was a POST. I should have made the time for this earlier, but I simply didn't have time. :-( Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Summary: - 307 means repeat the POST to the new URL *after user confirmation* - 303 means do a GET to the new URL - 301 means repeat the POST to the new URL *after user confirmation*, *but* old agents often do a GET instead - 302 may be treated the same as 303 (i.e. GET the new URL) for compatibility with existing practice This suggests to me that *no* automatic repeat of POST requests should ever be done, and that in the case of a 302 or 303 response, a POST should be replaced by a GET; this may also be done for a 301 response -- even though the standard calls that an error, it admits that it is done by old clients. But the new code in urllib.py doesn't seem to do that: it treats 301, 302 and 303 all the same, doing a POST if the original request was a POST (POST is determined by 'data is not None'). And it doesn't redirect on a 307 at all, even though it should do that if the original request was GET. The updated documentation describes the desired behavior for 301,302,303. I think the desired behavior can be obtained by always omitting the data argument in the call to self.open(newurl) in redirect_internal(). Then a handler for 307 could be handled that raises an error if the original request was a POST, and redirects otherwise. I'm attaching a suggested patch to urllib.py (guido.txt). It appears urllib2.py was patched correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-25 10:21 Message: Logged In: YES user_id=80475 Backported to 2.2.3. Closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 17:49 Message: Logged In: YES user_id=6380 Yes, I think that would be a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 17:34 Message: Logged In: YES user_id=80475 Committed as: Lib/urllib.py 1.157 Lib/urllib2.py 1.39 Doc/lib/liburllib.tex 1.47 Doc/lib/liburllib2.tex 1.7 Guido, would you like this backported to 2.2.3? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-20 22:44 Message: Logged In: YES user_id=261020 Just noticed that I forgot to upload one of the doc patches on 2003-03-05. Here it is. The patches that need to be applied are the three I uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch and liburllib2.tex.patch), and the liburllib.tex.patch I just uploaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 22:35 Message: Logged In: YES user_id=6380 I think this is the right thing to do. Can you check it in? (There are several files -- urllib, urllib2, and its docs). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-16 22:27 Message: Logged In: YES user_id=80475 Do you have time to take this one back? My head starts to explode when researching whether this is the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 21:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 22:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 17:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 17:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 03:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 23:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 20:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 18:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 19:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 21:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 02:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 23:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 23:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 23:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 17:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 20:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 18:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 02:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 18:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Thu Jul 10 23:15:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 15:15:14 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-767592 ] unittest docs don't suggest "unittest.main()" Message-ID: Feature Requests item #767592, was opened at 2003-07-08 02:40 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=767592&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Andrew Bennetts (spiv) Assigned to: Raymond Hettinger (rhettinger) Summary: unittest docs don't suggest "unittest.main()" Initial Comment: By far the most common use of the unittest module I've seen is simply: 1. Define one or more classes that subclass unittest.TestCase. Give them methods that are named "test_foo". 2. Put "if __name__ == '__main__': unittest.main()" at the bottom of the module. Nowhere do the unittest standard library docs make it clear this is the easiest, and most common, way to use the unittest module. The "Organizing test code" section completely fails to mention this, even though I think this should be the first thing described. Instead, it helpfully lists all sorts of ways to use test suites that you rarely, if ever, need in practice. Mention of unittest.main() is buried several sections later, and is very brief. I suggest opening "Organizing test code" with a complete working example demonstrating typical use, e.g.: --- import unittest class TestArithmetic(unittest.TestCase): def test_addition(self): self.failUnlessEqual(1+2, 3) if __name__ == '__main__': unittest.main() --- It's a trivial example, but it could work wonders. I usually recommend the diveintopython.org docs on unittest (http://diveintopython.org/roman_divein.html) due to the state of the official unittest docs. Thanks! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-10 17:15 Message: Logged In: YES user_id=80475 Added a new section that puts "what you need to know" all in one place at the beginning. Thanks for the bug report. See Doc/lib/libunittest.tex 1.14 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=767592&group_id=5470 From noreply@sourceforge.net Thu Jul 10 23:34:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 15:34:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-767645 ] incorrect os.path.supports_unicode_filenames Message-ID: Bugs item #767645, was opened at 2003-07-08 11:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect os.path.supports_unicode_filenames Initial Comment: At least on OSX, unicode file names are pretty much fully supported, yet os.path.supports_unicode_filenames is False (it comes from posixpath.py, which hard codes it). What would be a proper way to detect unicode filename support for posix platforms? ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-11 00:34 Message: Logged In: YES user_id=21627 >I'm not 100% sure, but I think the OS corrects that I'm relatively sure that the OS doesn't. The OS won't complain if you pass a file name that isn't UTF-8 at all - Finder will then fail to display the file correctly. There are CoreFoundationsBasicServicesSomething functions that you are supposed to call to correct that; Python does not use them. If you think setting the flag for darwin is fine in posixpath, just go ahead. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-10 23:13 Message: Logged In: YES user_id=92689 > On OSX, the situation is somewhat different from POSIX, as > you have additional functions to open files (which Python > apparently does not use, though), and because OSX specifies > that the byte strings have to be NFD UTF-8 (which Python > violates AFAICT). (I'm not 100% sure, but I think the OS corrects that) > True if arbitrary Unicode strings can be used as file names > (within limitations imposed by the file system), and if > \function{os.listdir()} returns Unicode strings for a Unicode > argument. > > While the first part is true for OSX, I don't think the > second part is. It is, we had a long discussion about that back when I implemented that ;-) > If that ever gets corrected (or verified), > no further detection is necessary - just set > macpath.supports_unicode_filenames for darwin (assuming you > use macpath.py on that system). Darwin is a posix platform, so I'll have to add a switch to posixpath.py. Unless you object to that, I will do that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:05 Message: Logged In: YES user_id=21627 Brett: As for "writing Unicode to an ASCII file system": there is no such thing. POSIX file systems accept arbitrary bytes, and don't interpret them except by looking at the path separator (in ASCII). So you can put Latin-1, KOI8-r, EUC-JP, UTF-8, gb2312, etc all on a single file system, and people actually do that. The convention is that bytes in file names are interpreted according to the locale's encoding. This is just a convention, and it has some significant flaws. Python follows that convention, meaning that you can use arbitrary Unicode strings in open(), as long as they are supported in the locale's encoding. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:01 Message: Logged In: YES user_id=21627 On POSIX platforms in general, detecting Unicode file name support is not possible. Posix uses open(2), and only open(2) (alon with creat(2), stat(2) etc) to access files. There is no open_w, or open_utf8, or the like. So file names are byte strings on Posix, and it will stay that way forever. (There is actually also fopen, but that doesn't change the situation at all). On OSX, the situation is somewhat different from POSIX, as you have additional functions to open files (which Python apparently does not use, though), and because OSX specifies that the byte strings have to be NFD UTF-8 (which Python violates AFAICT). The documentation for supports_unicode_filenames says True if arbitrary Unicode strings can be used as file names (within limitations imposed by the file system), and if \function{os.listdir()} returns Unicode strings for a Unicode argument. While the first part is true for OSX, I don't think the second part is. If that ever gets corrected (or verified), no further detection is necessary - just set macpath.supports_unicode_filenames for darwin (assuming you use macpath.py on that system). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 20:07 Message: Logged In: YES user_id=357491 What happens if you try to create a file using Unicode names? Could a test get the temp directory for the platform, write a file with Unicode in it, and then check for an error? Or if it always succeeds, write it, and then see if the results match? In other words, does writing Unicode to an ASCII file system ever lead to a mangling of the name? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 From noreply@sourceforge.net Fri Jul 11 01:00:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 17:00:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 17:04 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Later Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Martin v. Löwis (loewis) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-07-11 01:00 Message: Logged In: YES user_id=261020 Note that part of point 2. of my summary of 2003-05-10 is wrong, since 2.2.3 final contains the method urllib2.Request.get_method. I will upload another patch tomorrow, with that corrected. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-09 19:24 Message: Logged In: YES user_id=6380 I've asked on python-dev for help with this, as I expect I won't have time for it before July 17 (cut-off date for 2.3c1). Feel free to assign this to yourself if you want to grab it. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=261020 I tested the 301 behaviour of MSIE 5.00 on wine, and Mozilla Firebird 0.6. Both redirect POST to GET (without asking for user confirmation) on a 301 redirect, as expected, so it's probably justified to follow through with the 301 changes we discussed (summarised in my last message, along with a couple of related changes; item 1 has already been done). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 13:45 Message: Logged In: YES user_id=261020 Sorry for all these tiny updates. Summary of what remains to be done: 1. Apply Guido's patch for urllib.py: guido.txt. The docs are already correct. 2. 301 in response to POST is still not redirected in urllib2. urllib2.py.patch3 fixes that (note patch3, not patch2). It also removes my Request.get_method method (which now seems like overkill, as well as breaking the URL scheme-independence of Request). Also fixes an exception message. 3. liburllib2.tex.patch2 updates the docs to reflect the changes in urllib2.py.patch3, rephrases a note and adds a missing method description. 4. liburllib.tex.patch2: trivial rewording of docs for clarity. 5. Backport above changes to 2.2 bugfix branch. Jeremy in CVS: > The latest changes to the redirect handler couldn't possibly have been > tested, because they did not compute a newurl and failed with a > NameError. The __name__ == "__main__": block has a test for > redirects. Ah. The tests are preceeded by a warning about only working from a particular set of hosts: I mis-remembered, thinking that applied to *all* the tests. Sorry. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 01:14 Message: Logged In: YES user_id=261020 OK, I can't test IE, because Windows doesn't have a proper loopback adapter, and my Windows machine is disconnected. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 13:46 Message: Logged In: YES user_id=261020 Another test result on browser behaviour with 301 response to POST: lynx 2.8.4rel.1: offers user a choice between POST, GET and cancel Still haven't checked IE. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-07 15:21 Message: Logged In: YES user_id=261020 About 301: I tested Mozilla 1.0.0 and Konqueror 3.1.0 and they both redirect POST to GET without asking for confirmation. Ronald Tschalar tells me he tested Mozilla 1.1 and Netscape 4.7, and got the same result. So, all is as we had thought there (haven't checked IE, though). Side note: After reading another comment of Ronald's (he's the author of the HTTPClient java library), I realise that it would be a good idea to have urllib / urllib2 cache the results of 301 redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC says SHOULD happen. I'll file a separate bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-06 21:18 Message: Logged In: YES user_id=261020 What, a different urllib2 bug than the two that I uploaded patches for on 2003-04-27? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 01:27 Message: Logged In: YES user_id=6380 Note that Jeremy found a bug in what's currently checked in for urllib2.py. I'll try to sort this out coming Friday. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:33 Message: Logged In: YES user_id=261020 Damn this SF bug system. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-26 18:21 Message: Logged In: YES user_id=6380 Blech! Reopening. I just stumbled upon the relevant part of RFC 2616, and it suggests to me the following rules when the original request was a POST. I should have made the time for this earlier, but I simply didn't have time. :-( Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Summary: - 307 means repeat the POST to the new URL *after user confirmation* - 303 means do a GET to the new URL - 301 means repeat the POST to the new URL *after user confirmation*, *but* old agents often do a GET instead - 302 may be treated the same as 303 (i.e. GET the new URL) for compatibility with existing practice This suggests to me that *no* automatic repeat of POST requests should ever be done, and that in the case of a 302 or 303 response, a POST should be replaced by a GET; this may also be done for a 301 response -- even though the standard calls that an error, it admits that it is done by old clients. But the new code in urllib.py doesn't seem to do that: it treats 301, 302 and 303 all the same, doing a POST if the original request was a POST (POST is determined by 'data is not None'). And it doesn't redirect on a 307 at all, even though it should do that if the original request was GET. The updated documentation describes the desired behavior for 301,302,303. I think the desired behavior can be obtained by always omitting the data argument in the call to self.open(newurl) in redirect_internal(). Then a handler for 307 could be handled that raises an error if the original request was a POST, and redirects otherwise. I'm attaching a suggested patch to urllib.py (guido.txt). It appears urllib2.py was patched correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-25 09:21 Message: Logged In: YES user_id=80475 Backported to 2.2.3. Closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 16:49 Message: Logged In: YES user_id=6380 Yes, I think that would be a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 16:34 Message: Logged In: YES user_id=80475 Committed as: Lib/urllib.py 1.157 Lib/urllib2.py 1.39 Doc/lib/liburllib.tex 1.47 Doc/lib/liburllib2.tex 1.7 Guido, would you like this backported to 2.2.3? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-20 21:44 Message: Logged In: YES user_id=261020 Just noticed that I forgot to upload one of the doc patches on 2003-03-05. Here it is. The patches that need to be applied are the three I uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch and liburllib2.tex.patch), and the liburllib.tex.patch I just uploaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 21:35 Message: Logged In: YES user_id=6380 I think this is the right thing to do. Can you check it in? (There are several files -- urllib, urllib2, and its docs). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-16 21:27 Message: Logged In: YES user_id=80475 Do you have time to take this one back? My head starts to explode when researching whether this is the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 20:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 21:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 16:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 16:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 02:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 22:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 19:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 17:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Fri Jul 11 01:21:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 10 Jul 2003 17:21:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-769406 ] Droplets aren't always recognized as apps in MacPython 2.3b2 Message-ID: Bugs item #769406, was opened at 2003-07-10 17: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=769406&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Jack Jansen (jackjansen) Summary: Droplets aren't always recognized as apps in MacPython 2.3b2 Initial Comment: I am using MacPython 2.3b2 (installed via the 2.3b2-2 binary installer) on MacOS 10.2.3. I turned zappycfiles.py (from the Mac directory of the 2.3b2 source distribution, which I also have) into a drag-and-drop applet by dragging onto BuildApplet. On the whole it works fine (though no console for feedback and I've not figured out how to get one), but I am having two problems that are almost certainly caused by the same underlying problem: - The Dock does not acknowledge that it's an application. I cannot drag it into the usual app area of the dock. - DragThing (4.6.1, the current version) seems to agree with the Dock. It will not let me drag stuff onto it (even with "Check file types during drags" unchecked). Obviously more of an annoyance than a crisis, but I hope worth fixing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769406&group_id=5470 From noreply@sourceforge.net Fri Jul 11 08:48:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 00:48:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-767645 ] incorrect os.path.supports_unicode_filenames Message-ID: Bugs item #767645, was opened at 2003-07-08 11:42 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect os.path.supports_unicode_filenames Initial Comment: At least on OSX, unicode file names are pretty much fully supported, yet os.path.supports_unicode_filenames is False (it comes from posixpath.py, which hard codes it). What would be a proper way to detect unicode filename support for posix platforms? ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-11 09:48 Message: Logged In: YES user_id=92689 Done in rev. 1.61 of posixpath.py. (Actually, OSX does complain when you feed open() a non-valid utf-8 string (albeit with a misleading error message). The OS also makes sure the name is converted to its preferred form, eg. if I create a file named u'\xc7', I can also open it as u'C\u0327', and os.listdir() will always show the latter, no matter how you created the file.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-11 00:34 Message: Logged In: YES user_id=21627 >I'm not 100% sure, but I think the OS corrects that I'm relatively sure that the OS doesn't. The OS won't complain if you pass a file name that isn't UTF-8 at all - Finder will then fail to display the file correctly. There are CoreFoundationsBasicServicesSomething functions that you are supposed to call to correct that; Python does not use them. If you think setting the flag for darwin is fine in posixpath, just go ahead. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-10 23:13 Message: Logged In: YES user_id=92689 > On OSX, the situation is somewhat different from POSIX, as > you have additional functions to open files (which Python > apparently does not use, though), and because OSX specifies > that the byte strings have to be NFD UTF-8 (which Python > violates AFAICT). (I'm not 100% sure, but I think the OS corrects that) > True if arbitrary Unicode strings can be used as file names > (within limitations imposed by the file system), and if > \function{os.listdir()} returns Unicode strings for a Unicode > argument. > > While the first part is true for OSX, I don't think the > second part is. It is, we had a long discussion about that back when I implemented that ;-) > If that ever gets corrected (or verified), > no further detection is necessary - just set > macpath.supports_unicode_filenames for darwin (assuming you > use macpath.py on that system). Darwin is a posix platform, so I'll have to add a switch to posixpath.py. Unless you object to that, I will do that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:05 Message: Logged In: YES user_id=21627 Brett: As for "writing Unicode to an ASCII file system": there is no such thing. POSIX file systems accept arbitrary bytes, and don't interpret them except by looking at the path separator (in ASCII). So you can put Latin-1, KOI8-r, EUC-JP, UTF-8, gb2312, etc all on a single file system, and people actually do that. The convention is that bytes in file names are interpreted according to the locale's encoding. This is just a convention, and it has some significant flaws. Python follows that convention, meaning that you can use arbitrary Unicode strings in open(), as long as they are supported in the locale's encoding. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:01 Message: Logged In: YES user_id=21627 On POSIX platforms in general, detecting Unicode file name support is not possible. Posix uses open(2), and only open(2) (alon with creat(2), stat(2) etc) to access files. There is no open_w, or open_utf8, or the like. So file names are byte strings on Posix, and it will stay that way forever. (There is actually also fopen, but that doesn't change the situation at all). On OSX, the situation is somewhat different from POSIX, as you have additional functions to open files (which Python apparently does not use, though), and because OSX specifies that the byte strings have to be NFD UTF-8 (which Python violates AFAICT). The documentation for supports_unicode_filenames says True if arbitrary Unicode strings can be used as file names (within limitations imposed by the file system), and if \function{os.listdir()} returns Unicode strings for a Unicode argument. While the first part is true for OSX, I don't think the second part is. If that ever gets corrected (or verified), no further detection is necessary - just set macpath.supports_unicode_filenames for darwin (assuming you use macpath.py on that system). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 20:07 Message: Logged In: YES user_id=357491 What happens if you try to create a file using Unicode names? Could a test get the temp directory for the platform, write a file with Unicode in it, and then check for an error? Or if it always succeeds, write it, and then see if the results match? In other words, does writing Unicode to an ASCII file system ever lead to a mangling of the name? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 From noreply@sourceforge.net Fri Jul 11 11:42:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 03:42:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-769569 ] weird/buggy inspect.getsource behavious Message-ID: Bugs item #769569, was opened at 2003-07-11 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=769569&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Sebastien de Menten (sdementen) Assigned to: Nobody/Anonymous (nobody) Summary: weird/buggy inspect.getsource behavious Initial Comment: Using python 2.2.2 on a mandrake 9.1 with the inspect.py of python 2.2.3 (correction for lambda keyword), I run the following code """ import inspect a = [ None, lambda x: x>1 and x<0, None] print "Ok",inspect.getsource(a[1]) if 1: a = [ None, lambda x: x>1 and x<0, None] print "Ko",inspect.getsource(a[1]) """ Two weird behaviours occurs 1. The line "print "Ok",inspect.getsource(a[1])" prints Ok lambda x: x>1 and x<0, None] It prints a superfluous line. 2. The line "print "Ko",inspect.getsource(a[1])" raises an exception Ko Traceback (most recent call last): File "bug-inspect.py", line 13, in ? print "Ko",inspect.getsource(a[1]) File "/usr/lib/python2.2/inspect.py", line 523, in getsource lines, lnum = getsourcelines(object) File "/usr/lib/python2.2/inspect.py", line 515, in getsourcelines else: return getblock(lines[lnum:]), lnum + 1 File "/usr/lib/python2.2/inspect.py", line 498, in getblock tokenize.tokenize(ListReader(lines).readline, BlockFinder().tokeneater) File "/usr/lib/python2.2/tokenize.py", line 138, in tokenize tokenize_loop(readline, tokeneater) File "/usr/lib/python2.2/tokenize.py", line 144, in tokenize_loop for token_info in generate_tokens(readline): File "/usr/lib/python2.2/tokenize.py", line 218, in generate_tokens raise TokenError, ("EOF in multi-line statement", (lnum, 0)) tokenize.TokenError: ('EOF in multi-line statement', (7, 0)) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769569&group_id=5470 From noreply@sourceforge.net Fri Jul 11 12:12:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 04:12:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-764560 ] python treats IRIX64 and IRIX as different, but they are the Message-ID: Bugs item #764560, was opened at 2003-07-02 13:38 Message generated for change (Comment added) made by gmlack You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764560&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Gordon Lack (gmlack) Assigned to: Martin v. Löwis (loewis) Summary: python treats IRIX64 and IRIX as different, but they are the Initial Comment: Related to bug 216255 (116255?), but this goes deeper, as it refers to the *running* of python rather than just its building. If I build python on an Irix6.5 system (that is new/large) the tag "irix646" is used in the build/temp.* directory (and Lib/plat-*). This has several effects: a) the plat-irix6 directory from the standard distribution is ignored. b) running the tests on an IRIX system after compiling on an IRIX64 one causes it to rebuild everything, as it will look for temp.irix-6.5-2.2 and lib.irix-6.5-2.2 in build/ rather than the temp.irix64-6.5-2.2 and lib.irix64-6.5-2.2 which were actually built. c) running the same executable on a smaller system (a single installation, NFS mounted onto a large number of systems, for which "uname -s" returns IRIX, not IRIX64) will cause it to fail to find the </python2.2/Lib/plat-irix646 directory. (This might also affect 3rd party module installation?). IRIX and IRIX64 are the same when you build n32 binaries (which is what is built by default). Python should treat them the same. It should be possible to *configure* this OS tag at configure time (which would avoid this problem). Also, installing the "plat-irix646" directories under <> rather than <> would remove the need for such a tag in the installed files. ---------------------------------------------------------------------- >Comment By: Gordon Lack (gmlack) Date: 2003-07-11 12:12 Message: Logged In: YES user_id=88015 I thought I had checked the box - I'll try again.... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 21:47 Message: Logged In: YES user_id=21627 There is no attachment. Can you please check the checkbox? ---------------------------------------------------------------------- Comment By: Gordon Lack (gmlack) Date: 2003-07-09 14:14 Message: Logged In: YES user_id=88015 Ok - to fix this *particular* part of the problem turns out to be simple. (I had tried setting MACHDEP in my environment, but that fails as, if MACHDEP is set, then the configure script does not set ac_sys_system and ac_sys_release so tests on these fail to get done). So, attached is the patch which equates the two. NOTE: There are other build problems. The SGI C linker (and OSF1) uses -rpath not -R, and the extension buuilding scripts don't knwo how to handle this...but I suppose these would be for a different bug report. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 17:32 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=105470&aid=764560&group_id=5470 From noreply@sourceforge.net Fri Jul 11 16:45:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 08:45:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 17:04 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None Status: Open Resolution: Later Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Martin v. Löwis (loewis) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: John J Lee (jjlee) Date: 2003-07-11 16:45 Message: Logged In: YES user_id=261020 I am just about to upload three patches named *.patch4, which should finally close this bug. The important change is that 301 response to a POST is now automatically redirected. The rest is minor docstring and documentation fixes. They need backporting to 2.2 -- I haven't included separate patches since the changes are trivial. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-11 01:00 Message: Logged In: YES user_id=261020 Note that part of point 2. of my summary of 2003-05-10 is wrong, since 2.2.3 final contains the method urllib2.Request.get_method. I will upload another patch tomorrow, with that corrected. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-09 19:24 Message: Logged In: YES user_id=6380 I've asked on python-dev for help with this, as I expect I won't have time for it before July 17 (cut-off date for 2.3c1). Feel free to assign this to yourself if you want to grab it. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-22 19:33 Message: Logged In: YES user_id=261020 I tested the 301 behaviour of MSIE 5.00 on wine, and Mozilla Firebird 0.6. Both redirect POST to GET (without asking for user confirmation) on a 301 redirect, as expected, so it's probably justified to follow through with the 301 changes we discussed (summarised in my last message, along with a couple of related changes; item 1 has already been done). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 13:45 Message: Logged In: YES user_id=261020 Sorry for all these tiny updates. Summary of what remains to be done: 1. Apply Guido's patch for urllib.py: guido.txt. The docs are already correct. 2. 301 in response to POST is still not redirected in urllib2. urllib2.py.patch3 fixes that (note patch3, not patch2). It also removes my Request.get_method method (which now seems like overkill, as well as breaking the URL scheme-independence of Request). Also fixes an exception message. 3. liburllib2.tex.patch2 updates the docs to reflect the changes in urllib2.py.patch3, rephrases a note and adds a missing method description. 4. liburllib.tex.patch2: trivial rewording of docs for clarity. 5. Backport above changes to 2.2 bugfix branch. Jeremy in CVS: > The latest changes to the redirect handler couldn't possibly have been > tested, because they did not compute a newurl and failed with a > NameError. The __name__ == "__main__": block has a test for > redirects. Ah. The tests are preceeded by a warning about only working from a particular set of hosts: I mis-remembered, thinking that applied to *all* the tests. Sorry. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 01:14 Message: Logged In: YES user_id=261020 OK, I can't test IE, because Windows doesn't have a proper loopback adapter, and my Windows machine is disconnected. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 13:46 Message: Logged In: YES user_id=261020 Another test result on browser behaviour with 301 response to POST: lynx 2.8.4rel.1: offers user a choice between POST, GET and cancel Still haven't checked IE. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-07 15:21 Message: Logged In: YES user_id=261020 About 301: I tested Mozilla 1.0.0 and Konqueror 3.1.0 and they both redirect POST to GET without asking for confirmation. Ronald Tschalar tells me he tested Mozilla 1.1 and Netscape 4.7, and got the same result. So, all is as we had thought there (haven't checked IE, though). Side note: After reading another comment of Ronald's (he's the author of the HTTPClient java library), I realise that it would be a good idea to have urllib / urllib2 cache the results of 301 redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC says SHOULD happen. I'll file a separate bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-06 21:18 Message: Logged In: YES user_id=261020 What, a different urllib2 bug than the two that I uploaded patches for on 2003-04-27? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 01:27 Message: Logged In: YES user_id=6380 Note that Jeremy found a bug in what's currently checked in for urllib2.py. I'll try to sort this out coming Friday. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:33 Message: Logged In: YES user_id=261020 Damn this SF bug system. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 02:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-26 18:21 Message: Logged In: YES user_id=6380 Blech! Reopening. I just stumbled upon the relevant part of RFC 2616, and it suggests to me the following rules when the original request was a POST. I should have made the time for this earlier, but I simply didn't have time. :-( Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Summary: - 307 means repeat the POST to the new URL *after user confirmation* - 303 means do a GET to the new URL - 301 means repeat the POST to the new URL *after user confirmation*, *but* old agents often do a GET instead - 302 may be treated the same as 303 (i.e. GET the new URL) for compatibility with existing practice This suggests to me that *no* automatic repeat of POST requests should ever be done, and that in the case of a 302 or 303 response, a POST should be replaced by a GET; this may also be done for a 301 response -- even though the standard calls that an error, it admits that it is done by old clients. But the new code in urllib.py doesn't seem to do that: it treats 301, 302 and 303 all the same, doing a POST if the original request was a POST (POST is determined by 'data is not None'). And it doesn't redirect on a 307 at all, even though it should do that if the original request was GET. The updated documentation describes the desired behavior for 301,302,303. I think the desired behavior can be obtained by always omitting the data argument in the call to self.open(newurl) in redirect_internal(). Then a handler for 307 could be handled that raises an error if the original request was a POST, and redirects otherwise. I'm attaching a suggested patch to urllib.py (guido.txt). It appears urllib2.py was patched correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-25 09:21 Message: Logged In: YES user_id=80475 Backported to 2.2.3. Closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 16:49 Message: Logged In: YES user_id=6380 Yes, I think that would be a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 16:34 Message: Logged In: YES user_id=80475 Committed as: Lib/urllib.py 1.157 Lib/urllib2.py 1.39 Doc/lib/liburllib.tex 1.47 Doc/lib/liburllib2.tex 1.7 Guido, would you like this backported to 2.2.3? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-20 21:44 Message: Logged In: YES user_id=261020 Just noticed that I forgot to upload one of the doc patches on 2003-03-05. Here it is. The patches that need to be applied are the three I uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch and liburllib2.tex.patch), and the liburllib.tex.patch I just uploaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 21:35 Message: Logged In: YES user_id=6380 I think this is the right thing to do. Can you check it in? (There are several files -- urllib, urllib2, and its docs). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-16 21:27 Message: Logged In: YES user_id=80475 Do you have time to take this one back? My head starts to explode when researching whether this is the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 20:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 21:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 16:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 16:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 02:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 22:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 19:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 17:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 18:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 20:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 01:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 22:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 22:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 16:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 19:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 17:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 01:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 17:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Fri Jul 11 17:22:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 09:22:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Comment added) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 16:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 13:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 05:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Fri Jul 11 17:32:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 09:32:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Comment added) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Nobody/Anonymous (nobody) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 16:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 13:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 05:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Fri Jul 11 19:22:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 11:22:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 08:49 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) >Assigned to: Kurt B. Kaiser (kbk) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 13:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 11:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 11:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 14:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 14:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 11:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 08:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 00:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Fri Jul 11 19:43:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 11:43:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Comment added) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Kurt B. Kaiser (kbk) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:43 Message: Logged In: YES user_id=819035 Sorry, my confusion. Since I edited my original config-keys.def file, I forgot that the [IDLE Classic Mac] shortcuts used the Command modifier, and not Alt. This confusion is only made in my last message. If you replace "Command" with "Alt" in that message, everything makes sense: """ If I change all keybinding using the Command-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Command, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. """ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 18:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 16:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 13:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 05:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Fri Jul 11 19:48:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 11:48:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Comment added) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Kurt B. Kaiser (kbk) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:48 Message: Logged In: YES user_id=819035 Using the original [IDLE Classic Mac] shortcut keys definitions, the only Command shortcuts that do anything are the following: Command-Q: tries to quit X11 instead of IDLE Command-W: closes X11 windows instead of IDLE windows Command-B: go to beginning of word Command-F: go to end of word Command-D: delete next word Command-H: hide X11 Command-M: minimize window Command-,: X11 preferences dialog ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:43 Message: Logged In: YES user_id=819035 Sorry, my confusion. Since I edited my original config-keys.def file, I forgot that the [IDLE Classic Mac] shortcuts used the Command modifier, and not Alt. This confusion is only made in my last message. If you replace "Command" with "Alt" in that message, everything makes sense: """ If I change all keybinding using the Command-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Command, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. """ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 18:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 16:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 13:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 05:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Fri Jul 11 20:08:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 12:08:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Comment added) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Kurt B. Kaiser (kbk) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 19:08 Message: Logged In: YES user_id=819035 The file extend.txt references two files that do not exist: keydefs and config.txt I suppose the former corresponds config-keys.def, while the latter has been split into 3 files: config-main.def, config-extensions.def and config-highlight.def. Is this correct? Looking into config-extensions.def, I can finally see were those non-standard key sequences are defined: [FormatParagraph_cfgBindings] format-paragraph= (...) [AutoExpand_cfgBindings] expand-word= (...) [ZoomHeight_cfgBindings] zoom-height= (...) [ScriptBinding_cfgBindings] run-module= check-module= It would nice if these key bindings for extension modules could be put in the same file as the standard key bindings. Even nicer if the configuration dialog could be used to change all key bindings. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:48 Message: Logged In: YES user_id=819035 Using the original [IDLE Classic Mac] shortcut keys definitions, the only Command shortcuts that do anything are the following: Command-Q: tries to quit X11 instead of IDLE Command-W: closes X11 windows instead of IDLE windows Command-B: go to beginning of word Command-F: go to end of word Command-D: delete next word Command-H: hide X11 Command-M: minimize window Command-,: X11 preferences dialog ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:43 Message: Logged In: YES user_id=819035 Sorry, my confusion. Since I edited my original config-keys.def file, I forgot that the [IDLE Classic Mac] shortcuts used the Command modifier, and not Alt. This confusion is only made in my last message. If you replace "Command" with "Alt" in that message, everything makes sense: """ If I change all keybinding using the Command-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Command, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. """ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 18:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 16:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 13:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 05:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Fri Jul 11 21:43:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 13:43:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 08:49 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Kurt B. Kaiser (kbk) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 15:43 Message: Logged In: YES user_id=149084 Thank you for reporting the issues with help.txt and extend.txt. I will update these files. You are correct about the renaming, extend.txt has not been updated since the new config system was implemented. I agree it would be nice to set the extension configuration from the configuration dialog. However, we are much too close to release to contemplate doing that for 2.3. The extension feature is intended to incorporate 3rd party features so the enhancement of the config dialog would have to be suitably general. Your problem appears to be down to one thing: none of IDLE's "Classic Mac" Command combinations in your config-keys.def work. If I understand you correctly, you are saying that e.g. replacing "Command-Key-w" by "Meta-Key-w" in config-keys.def causes the <> event to work correctly? Note that Tk is very picky about capitalization. "Command-Key-w" is not the same as "Command-Key-W". Please be sure that your file is correct in this regard. If you can get everything working by doing this, would you please upload the modified version of your config-keys.def and let me know what the remaining problems are, if any. In your messages you have variously said that both "Command-B" and "Ctl-b" keystrokes go to the beginning of a word. Is this correct? And do you really mean "Apple/Shift/b" in the first case? The Ctl-b binding and others like it that you have mentioned in your earlier message are part of a number of default Tk bindings that have not been disabled in IDLE. http://www.tcl.tk/man/tcl8.3/TkCmd/text.htm#M141 Clearly, there may not be complete compatibility with this documentation in the Tk Mac implementation. But that is the origin of the bindings. By the way, the way to customize is not to modify config-keys.def, but to modify your .idlerc/config-keys.cfg or any of the other files in that directory. That is what the config dialog does, and it is quite all right to modify it manually as long as you carefully follow the format. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 14:08 Message: Logged In: YES user_id=819035 The file extend.txt references two files that do not exist: keydefs and config.txt I suppose the former corresponds config-keys.def, while the latter has been split into 3 files: config-main.def, config-extensions.def and config-highlight.def. Is this correct? Looking into config-extensions.def, I can finally see were those non-standard key sequences are defined: [FormatParagraph_cfgBindings] format-paragraph= (...) [AutoExpand_cfgBindings] expand-word= (...) [ZoomHeight_cfgBindings] zoom-height= (...) [ScriptBinding_cfgBindings] run-module= check-module= It would nice if these key bindings for extension modules could be put in the same file as the standard key bindings. Even nicer if the configuration dialog could be used to change all key bindings. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 13:48 Message: Logged In: YES user_id=819035 Using the original [IDLE Classic Mac] shortcut keys definitions, the only Command shortcuts that do anything are the following: Command-Q: tries to quit X11 instead of IDLE Command-W: closes X11 windows instead of IDLE windows Command-B: go to beginning of word Command-F: go to end of word Command-D: delete next word Command-H: hide X11 Command-M: minimize window Command-,: X11 preferences dialog ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 13:43 Message: Logged In: YES user_id=819035 Sorry, my confusion. Since I edited my original config-keys.def file, I forgot that the [IDLE Classic Mac] shortcuts used the Command modifier, and not Alt. This confusion is only made in my last message. If you replace "Command" with "Alt" in that message, everything makes sense: """ If I change all keybinding using the Command-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Command, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. """ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 13:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 11:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 11:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 14:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 14:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 11:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 08:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 00:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Fri Jul 11 21:50:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 13:50:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-769861 ] "make info" croaks Message-ID: Bugs item #769861, was opened at 2003-07-11 15: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=769861&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: "make info" croaks Initial Comment: I noticed this problem mentioned on the fink list. In the Docs/info directory, executing "make" leads to an Emacs error: % pwd /Users/skip/src/python/head/dist/src/Doc/info % make Using emacs to build the info docs EMACS=emacs ../tools/mkinfo ../lib/lib.tex python-lib.texi python-lib.info emacs -batch -q --no-site-file -l /Users/skip/src/python/ head/dist/src/Doc/tools/py2texi.el --eval (setq py2texi-dirs '("./" "../texinputs/" "/Users/skip/src/python/head/dist/src/ Doc/lib")) --eval (setq py2texi-texi-file-name "python- lib.texi") --eval (setq py2texi-info-file-name "python- lib.info") --eval (py2texi "/Users/skip/src/python/head/dist/ src/Doc/lib/lib.tex") -f kill-emacs Mark set Args out of range: 405571, 405573 make: *** [python-lib.info] Error 255 The regular expression used to match Latex commands will skip over an optional argument, but that argument can't contain a right square bracket. This is okay: \versionchanged[foo bar baz]{2.3} but this is not \versionchanged[foo [bar] baz]{2.3} The \versionchanged macro at the end of libre.tex violates this property. I'm not sure what to do about it since regular expressions can't count nesting depth. A quick hack appears to be to change the search pattern in py2texi-process-commands to "\\\([a-zA-Z*]+\)\(\[[^}]*\]\)?" but I'm not sure what other side-effects that might have on the info file generation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769861&group_id=5470 From noreply@sourceforge.net Sat Jul 12 02:25:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 18:25:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-669838 ] Seg fault in gcmodule.c Message-ID: Bugs item #669838, was opened at 2003-01-17 12:03 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Popovitch (greg7mdp) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in gcmodule.c Initial Comment: Using Python 2.2.2 on Linux Redhat 7.2: Python 2.2.2 (#1, Oct 21 2002, 22:19:12) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 I have a crash which happens somewhat randomly (for example it goes away if I add a print statement somewhere). Here is some gdb info. lnx:0:usr/greg/ib> gdb python2.2 GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run rules.py > xx Starting program: /usr/local/bin/python2.2 rules.py > xx [New Thread 1024 (LWP 30182)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 30182)] 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 185 if (op && PyObject_IS_GC(op)) { (gdb) print op $1 = (PyObject *) 0x1000000 (gdb) print data $2 = (void *) 0x0 (gdb) where 20 #0 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 #1 0x080c9abb in dict_traverse (op=0x827bc34, visit=0x80996ec , arg=0x0) at Objects/dictobject.c:1589 #2 0x0809897e in collect (young=0x80ee5a0, old=0x80ee5ac) at Modules/gcmodule.c:201 #3 0x08099062 in collect_generations () at Modules/gcmodule.c:518 #4 0x08099576 in _PyObject_GC_New (tp=0x80f8ae0) at Modules/gcmodule.c:879 #5 0x080c7b75 in PyDict_New () at Objects/dictobject.c:161 #6 0x080869d5 in symtable_init () at Python/compile.c:4671 #7 0x08086910 in symtable_build (c=0xbfffea90, n=0x8240e68) at Python/compile.c:4261 #8 0x08084109 in jcompile (n=0x8240e68, filename=0x81f83ec "", base=0x0, flags=0xbfffebe4) at Python/compile.c:4111 #9 0x0808665e in PyNode_CompileFlags (n=0x8240e68, filename=0x81f83ec "", flags=0xbfffebe4) at Python/compile.c:4042 #10 0x080945c7 in Py_CompileStringFlags ( str=0x811f8bc "agrepy(\epreuve photographique\, 22, t, len(t), 0, re[0]) and re[1].search(t)", filename=0x81f83ec "", start=258, flags=0xbfffebe4) at Python/pythonrun.c:1133 #11 0x080cc4cc in builtin_compile (self=0x0, args=0x8241a04) at Python/bltinmodule.c:398 #12 0x080ca7cc in PyCFunction_Call (func=0x8105fb0, arg=0x8241a04, kw=0x0) at Objects/methodobject.c:100 #13 0x08077918 in eval_frame (f=0x81a6fbc) at Python/ceval.c:2014 #14 0x0807892b in PyEval_EvalCodeEx (co=0x81f8750, globals=0x8111ecc, locals=0x0, args=0x82ffe14, argcount=2, kws=0x82ffe1c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #15 0x0807aa43 in fast_function (func=0x815f754, pp_stack=0xbfffee14, n=2, na=2, nk=0) at Python/ceval.c:3173 #16 0x080779b5 in eval_frame (f=0x82ffc8c) at Python/ceval.c:2034 #17 0x0807892b in PyEval_EvalCodeEx (co=0x81f9768, globals=0x8111ecc, locals=0x0, args=0x81cc34c, argcount=3, kws=0x81cc358, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #18 0x0807aa43 in fast_function (func=0x815f78c, pp_stack=0xbfffef74, n=3, na=3, nk=0) at Python/ceval.c:3173 #19 0x080779b5 in eval_frame (f=0x81cc1f4) at Python/ceval.c:2034 (More stack frames follow...) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 20:25 Message: Logged In: YES user_id=80475 Greg, can you also try this with Py2.3b2+. We're about to release it and need to know if your bug is still present. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 16:52 Message: Logged In: YES user_id=33168 Gregory, do you still have this problem? Do you believe there is a bug or can we close this report? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-24 16:01 Message: Logged In: YES user_id=33168 After running configure, you must remove all the modules and rebuild them too. This doesn't happen by default. You can also do rm build/*/*.o build/*/*.so to remove the modules. make clean should also work. Have you tried running valgrind, purify, electric fence, or some other memory checker on the code. Perhaps there is a memory problem in the pyagrep module? ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-24 15:46 Message: Logged In: YES user_id=222034 It is hard to reproduce... I realized that the bug may be in a module I use called AGREPY downloadable from http://www.bio.cam.ac.uk/~mw263/pyagrep.html. I tried to reproduce my Python 2.2.2 install with "./configure --with- pydebug" as suggested, but then I get the following error: /usr/greg/soft/linux/python/Python-2.2.2/python rules.py Adding parser accelerators ... Done. Traceback (most recent call last): File "rules.py", line 39, in ? import string, os, agrepy ImportError: /usr/greg/soft/linux/python/Python- 2.2.2/build/lib.linux-i686-2.2/agrepy.so: undefined symbol: Py_InitModule4 [6589 refs] I was mistaken to suspect my use of the "exec" statement, which I replaced with "eval" and the problem still happened. It is not easy to come up with a reasonably small piece of code reproducing the problem! gregory ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-17 13:43 Message: Logged In: YES user_id=33168 Can you post any code which causes the crash, even if it only crashes sometimes? Can you build python with ./configure --with-pydebug and run your program? This may find the problem closer to the cause. ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-17 12:05 Message: Logged In: YES user_id=222034 I forgot to mention that this program is using the "exec()" builtin heavily, and I believe that the crash is related to this. gregory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 From noreply@sourceforge.net Sat Jul 12 02:33:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 18:33:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-663782 ] test_socket test_unicode_file fail on 2.3a1 on winNT Message-ID: Bugs item #663782, was opened at 2003-01-07 10:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_socket test_unicode_file fail on 2.3a1 on winNT Initial Comment: This happens after installing 2.3a1 on winNT 4 sp6. D:\apps\Python23>python D:\apps\Python23\Lib\test\test_socket.py testCrucialConstants (__main__.GeneralModuleTests) ... ok testDefaultTimeout (__main__.GeneralModuleTests) ... ok testGetServByName (__main__.GeneralModuleTests) ... ok testGetSockOpt (__main__.GeneralModuleTests) ... ok testHostnameRes (__main__.GeneralModuleTests) ... ok testInterpreterCrash (__main__.GeneralModuleTests) ... ok testNtoH (__main__.GeneralModuleTests) ... ok testRefCountGetNameInfo (__main__.GeneralModuleTests) ... ok testSendAfterClose (__main__.GeneralModuleTests) ... ok testSetSockOpt (__main__.GeneralModuleTests) ... ok testSockName (__main__.GeneralModuleTests) ... ok testSocketError (__main__.GeneralModuleTests) ... ok testFromFd (__main__.BasicTCPTest) ... ok testOverFlowRecv (__main__.BasicTCPTest) ... ok testOverFlowRecvFrom (__main__.BasicTCPTest) ... ok testRecv (__main__.BasicTCPTest) ... ok testRecvFrom (__main__.BasicTCPTest) ... ok testSendAll (__main__.BasicTCPTest) ... ok testShutdown (__main__.BasicTCPTest) ... ok testRecvFrom (__main__.BasicUDPTest) ... ok testSendtoAndRecv (__main__.BasicUDPTest) ... ok testAccept (__main__.NonBlockingTCPTests) ... FAIL ERROR testConnect (__main__.NonBlockingTCPTests) ... ok testRecv (__main__.NonBlockingTCPTests) ... ok testSetBlocking (__main__.NonBlockingTCPTests) ... ok testFullRead (__main__.FileObjectClassTestCase) ... ok testReadline (__main__.FileObjectClassTestCase) ... ok testSmallRead (__main__.FileObjectClassTestCase) ... ok testUnbufferedRead (__main__.FileObjectClassTestCase) ... ok testFullRead (__main__.UnbufferedFileObjectClassTestCase) ... ok testReadline (__main__.UnbufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.UnbufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.UnbufferedFileObjectClassTestCase) ... ok testUnbufferedReadline (__main__.UnbufferedFileObjectClassTestCase) ... ok testFullRead (__main__.LineBufferedFileObjectClassTestCase) ... ok testReadline (__main__.LineBufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.LineBufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.LineBufferedFileObjectClassTestCase) ... ok testFullRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok testReadline (__main__.SmallBufferedFileObjectClassTestCase) ... ok testSmallRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok testUnbufferedRead (__main__.SmallBufferedFileObjectClassTestCase) ... ok ====================================================================== ERROR: testAccept (__main__.NonBlockingTCPTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_socket.py", line 117, in _tearDown self.fail(msg) File "D:\apps\Python23\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: (10061, 'Connection refused') ====================================================================== FAIL: testAccept (__main__.NonBlockingTCPTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_socket.py", line 475, in testAccept self.fail("Error trying to do non-blocking accept.") File "D:\apps\Python23\lib\unittest.py", line 260, in fail raise self.failureException, msg AssertionError: Error trying to do non-blocking accept. ---------------------------------------------------------------------- Ran 42 tests in 2.204s FAILED (failures=1, errors=1) Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_socket.py", line 632, in ? test_main() File "D:\apps\Python23\Lib\test\test_socket.py", line 629, in test_main test_support.run_suite(suite) File "D:\apps\Python23\lib\test\test_support.py", line 217, in run_suite raise TestFailed(msg) test.test_support.TestFailed: errors occurred; run in verbose mode for details D:\apps\Python23>python D:\apps\Python23\Lib\test\test_unicode_file.py File doesn't exist (encoded string) after creating it Traceback (most recent call last): File "D:\apps\Python23\Lib\test\test_unicode_file.py", line 37, in ? if os.stat(TESTFN_ENCODED) != os.stat(TESTFN_UNICODE): OSError: [Errno 2] No such file or directory: '@test-??' ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 20:33 Message: Logged In: YES user_id=80475 Based on irmen's test, I'll mark this as fixed and close it. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-05-25 03:03 Message: Logged In: YES user_id=358087 As far as I recall it does. (I've lost my job so I don't have access to NT anymore). Miki ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 16:55 Message: Logged In: YES user_id=33168 Miki, are you still having this problem with 2.3b1? Can this be closed? ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2003-04-26 12:14 Message: Logged In: YES user_id=129426 Both tests run fine on my windows XP box with Python 2.3b... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-24 23:03 Message: Logged In: YES user_id=31435 I personally tested these before the releases, on Win98SE and on Win2000 Pro. No problems there, although test_unicode_file turns itself off on Win9x. I don't have access to an NT box, and these won't get fixed until a Python developer who does have NT can dig into them there. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-03-24 02:51 Message: Logged In: YES user_id=358087 Yes. Version is: 2.3a2 (#39, Feb 19 2003, 17:58:58) [MSC v.1200 32 bit (Intel)] ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-23 15:40 Message: Logged In: YES user_id=33168 Is this problem still happening with 2.3a2+ ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=663782&group_id=5470 From noreply@sourceforge.net Sat Jul 12 02:36:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 18:36:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-651701 ] Bozo getstate w/ slots overrides base Message-ID: Bugs item #651701, was opened at 2002-12-10 18:10 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651701&group_id=5470 Category: Type/class unification Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Fein (pafein) Assigned to: Nobody/Anonymous (nobody) Summary: Bozo getstate w/ slots overrides base Initial Comment: The bozo __getstate__ set automatically on classes defining __slots__ overrides any __getstate__ defined in a base class. This makes writing a mixin to implement this method impossible. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 20:36 Message: Logged In: YES user_id=80475 Peter, is this still an issue? Can you attach a script demonstrating the problem? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:15 Message: Logged In: YES user_id=33168 There was an issue with that, IIRC. There was a discussion on python-dev a while ago which Guido talked about the issues. I don't remember when or what the issues were. Probably about 3-6 months ago. I think the code in this area may have changed, so it would be beneficial to test with 2.3b1. ---------------------------------------------------------------------- Comment By: Peter Fein (pafein) Date: 2003-05-22 17:09 Message: Logged In: YES user_id=639329 This issue is that although the base class B defines a __getstate__, the class C2 overrides it b/c it contains __slots__. Basically, I'm suggesting that base classes should be checked for getstate instead of only looking at the class that defines slots before adding the bozo'd version. Unfortunately, I don't have a 2.3* version to play with at the moment. Please let me know if this clarifies things. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 16:58 Message: Logged In: YES user_id=33168 What do you expect to be printed? I'm not sure what you want changed. Have you tested with 2.3b1? Does this meet your needs? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=651701&group_id=5470 From noreply@sourceforge.net Sat Jul 12 02:46:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 18:46:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-645629 ] SequenceMatcher finds suboptimal sequenc Message-ID: Bugs item #645629, was opened at 2002-11-29 05:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645629&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Wont Fix Priority: 3 Submitted By: David Necas (yeti-dn) Assigned to: Tim Peters (tim_one) Summary: SequenceMatcher finds suboptimal sequenc Initial Comment: The algorithm used for approximate string matching doesn't find the optimal edit sequence (it finds longest blocks instead). Example: >>> from difflib import SequenceMatcher >>> sm = SequenceMatcher() >>> sm.set_seqs('axfot', 'aoftax') >>> sm.ratio() 0.36363636363636365 >>> sm.get_matching_blocks() [(0, 4, 2), (5, 6, 0)] >>> sm.get_opcodes() [('insert', 0, 0, 0, 4), ('equal', 0, 2, 4, 6), ('delete', 2, 5, 6, 6)] What's wrong? Levenshtein distance with weight 2 for item replacement is only 5 (the weight 2 corresponds to what ratio() is supposed to compute, the classic Levenshtein distance is 4), so one would expect to get similarity (i.e. ratio()) (11-5)/11 = 6/11 = 0.545454545454..., and not only 4/11. And really, the maximal matching blocks are: [(0, 0, 1), (2, 2, 1), (4, 3, 1)] and the minimal edit sequence is: [('equal', 0, 1, 0, 1), ('replace', 1, 2, 1, 2), ('equal', 2, 3, 2, 3), ('delete', 3, 4, 3, 3), ('equal', 4, 5, 3, 4), ('insert', 5, 5, 4, 6)] The impact of this ``feature'' on diff-like applications may be even positive, beause the edit sequence then consists of smaller number of operations on lager chunks. Thus I'm not sure if this is something which should be fixed. However, it should be at least noted in the documentation the ratio() function gives only a lower bound of the string similarity (so people like me won't be tempted to use it to check results of their own Levenshtein distance/string similarity implementation). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 20:46 Message: Logged In: YES user_id=80475 I looked at possible wording changes but prefer the docs as they stand. Others have found the docs to be perfectly clear. Any more text about worse case ratios to minimal edit distances would, IMO, be a distractor and make the docs less clear. Marking this one as won't fix and closing. We do appreciate the report. Since this is an area of interest for you, consider designing a plug-in replacement using the Levenshtein algorithm and post it to the Vaults of Parnassus or in ActiveState's cookbook. That would provide some benefit to the occassional seeker of a minimal edit sequence. ---------------------------------------------------------------------- Comment By: David Necas (yeti-dn) Date: 2002-11-29 23:15 Message: Logged In: YES user_id=658986 OK, I know it's not Levenshtein because I've read the source, and I agree I should really read the docs first and the source after, it's actually written in the docs. However, the docs say `This does not yield minimal edit sequences, but does tend to yield matches that ``look right'' to people.' This is not true -- see my last posting. Or perhaps you really think matching `Observation' looks better to people than matching the smaller parts from the rest of the string (which I strongly doubt). Then please add a note the matches it finds can be arbitrarily bad, at least (e.g., the ratio between optimal and difflib's best match can be as big as (N-1)^2/4N, where N is sequence length (of both sequecnes)). Thank you. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-11-29 11:03 Message: Logged In: YES user_id=31435 Please read the docs first. This isn't the Levenshtein algorithm, and it doesn't care about finding minimal edit distance. ---------------------------------------------------------------------- Comment By: David Necas (yeti-dn) Date: 2002-11-29 07:58 Message: Logged In: YES user_id=658986 Sorry, I've changed my mind. This definitely should be fixed. In following strings finding `Observation' effectively inhibits finding the much better match: sm.set_seqs('Observation: What seems as a small glitch at the first sight may have large impact', 'What-seems-as-a-small-glitch-at-the-first-sight-may-have-large-impact (Observation)') Unfortunately this probably means complete rewrite, I can't see how the current algorithm could be changed to work in this case (but I don't understand it 100%, so maybe...). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=645629&group_id=5470 From noreply@sourceforge.net Sat Jul 12 02:52:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 18:52:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-502544 ] __slots__ undocumented Message-ID: Bugs item #502544, was opened at 2002-01-11 18:26 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=502544&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Frank Tobin (ftobin) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: __slots__ undocumented Initial Comment: Simply put, there is no documentation describing __slots__. A mere grep shows this. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 20:52 Message: Logged In: YES user_id=80475 Fixed. See Doc/ref/ref3.tex 1.107 for Py2.3. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-01-11 18:40 Message: Logged In: YES user_id=6380 Not in the core docs, but in the mean time there's a lot of detail on __slots__ in http://www.python.org/2.2/descrintro.html. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=502544&group_id=5470 From noreply@sourceforge.net Sat Jul 12 03:01:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 19:01:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-479698 ] __coerce__ not working with new classes Message-ID: Bugs item #479698, was opened at 2001-11-08 13:53 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=479698&group_id=5470 Category: Documentation Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: __coerce__ not working with new classes Initial Comment: I converted a numeric-like class from the "old-style" Python class to the "new-style" Python class by inheriting from "object". Numerical operations like "__mul__" and "__div__" failed with the "new-style" class. After tracking the problem, I found that the "__coerce__" special method was called when performing mixed-type arithmetic, as expected, with the "old-style" class, but not with the "new-style" class. The arithmetic operations failed because the expected type conversion was not performed with the mixed-type arithmetic. As best I can tell, without examining the Python source code, the following is taking place: 1. The documentation for the "__coerce__" special method states that it is invoked in the case of mixed-type arithmetic only if at least one of the arguments in an arithmetic operation is a class instance. 2. An object created with an "old-style" class is of type "instance", as verified by the "type" function, i.e. 3. An object created with a "new-style" class is of a different type, as also verified by the "type function, i.e. Evidently, because of this change in type, the "__coerce__" function is not longer invoked for "new-style" Python classes. Gary H. Loechelt ON Semiconductor ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 21:01 Message: Logged In: YES user_id=80475 Fred fixed this in the docs on June 4, 2002. See Doc/ref/ref3.tex 1.190. Marking a closed. Thanks for the bug report and thorough analysis. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2001-12-03 14:09 Message: Logged In: YES user_id=6380 Encouraged by the submittor's comment, I've decided not to fix this. New-style class instances cannot be old-style numbers, and the conversion from old-style class to new-style class will have to involve changing any numeric operators to do their own coercions. I'll leave this as a documentation item, at a lower priority (I'll add something to the docs on the web). ---------------------------------------------------------------------- Comment By: Gary H. Loechelt (loechelt) Date: 2001-11-26 10:59 Message: Logged In: YES user_id=142817 After further looking into this, I am not sure that it is a bug "per se". It may have been the intentionally designed behavior. It is certainly possible for a user to rewrite arithmetic methods (i.e. '__add__') to explicitly call a coerce method. However, in the very least, changing from the "old-style" to the "new-style" class does break existing code that relies upon the '__coerce__' method, and this fact is not very well documented. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=479698&group_id=5470 From noreply@sourceforge.net Sat Jul 12 03:06:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 19:06:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-669838 ] Seg fault in gcmodule.c Message-ID: Bugs item #669838, was opened at 2003-01-17 12:03 Message generated for change (Comment added) made by greg7mdp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Popovitch (greg7mdp) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in gcmodule.c Initial Comment: Using Python 2.2.2 on Linux Redhat 7.2: Python 2.2.2 (#1, Oct 21 2002, 22:19:12) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 I have a crash which happens somewhat randomly (for example it goes away if I add a print statement somewhere). Here is some gdb info. lnx:0:usr/greg/ib> gdb python2.2 GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run rules.py > xx Starting program: /usr/local/bin/python2.2 rules.py > xx [New Thread 1024 (LWP 30182)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 30182)] 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 185 if (op && PyObject_IS_GC(op)) { (gdb) print op $1 = (PyObject *) 0x1000000 (gdb) print data $2 = (void *) 0x0 (gdb) where 20 #0 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 #1 0x080c9abb in dict_traverse (op=0x827bc34, visit=0x80996ec , arg=0x0) at Objects/dictobject.c:1589 #2 0x0809897e in collect (young=0x80ee5a0, old=0x80ee5ac) at Modules/gcmodule.c:201 #3 0x08099062 in collect_generations () at Modules/gcmodule.c:518 #4 0x08099576 in _PyObject_GC_New (tp=0x80f8ae0) at Modules/gcmodule.c:879 #5 0x080c7b75 in PyDict_New () at Objects/dictobject.c:161 #6 0x080869d5 in symtable_init () at Python/compile.c:4671 #7 0x08086910 in symtable_build (c=0xbfffea90, n=0x8240e68) at Python/compile.c:4261 #8 0x08084109 in jcompile (n=0x8240e68, filename=0x81f83ec "", base=0x0, flags=0xbfffebe4) at Python/compile.c:4111 #9 0x0808665e in PyNode_CompileFlags (n=0x8240e68, filename=0x81f83ec "", flags=0xbfffebe4) at Python/compile.c:4042 #10 0x080945c7 in Py_CompileStringFlags ( str=0x811f8bc "agrepy(\epreuve photographique\, 22, t, len(t), 0, re[0]) and re[1].search(t)", filename=0x81f83ec "", start=258, flags=0xbfffebe4) at Python/pythonrun.c:1133 #11 0x080cc4cc in builtin_compile (self=0x0, args=0x8241a04) at Python/bltinmodule.c:398 #12 0x080ca7cc in PyCFunction_Call (func=0x8105fb0, arg=0x8241a04, kw=0x0) at Objects/methodobject.c:100 #13 0x08077918 in eval_frame (f=0x81a6fbc) at Python/ceval.c:2014 #14 0x0807892b in PyEval_EvalCodeEx (co=0x81f8750, globals=0x8111ecc, locals=0x0, args=0x82ffe14, argcount=2, kws=0x82ffe1c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #15 0x0807aa43 in fast_function (func=0x815f754, pp_stack=0xbfffee14, n=2, na=2, nk=0) at Python/ceval.c:3173 #16 0x080779b5 in eval_frame (f=0x82ffc8c) at Python/ceval.c:2034 #17 0x0807892b in PyEval_EvalCodeEx (co=0x81f9768, globals=0x8111ecc, locals=0x0, args=0x81cc34c, argcount=3, kws=0x81cc358, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #18 0x0807aa43 in fast_function (func=0x815f78c, pp_stack=0xbfffef74, n=3, na=3, nk=0) at Python/ceval.c:3173 #19 0x080779b5 in eval_frame (f=0x81cc1f4) at Python/ceval.c:2034 (More stack frames follow...) ---------------------------------------------------------------------- >Comment By: Gregory Popovitch (greg7mdp) Date: 2003-07-11 22:06 Message: Logged In: YES user_id=222034 Sorry, I had responded earlier via email but it didn't make it in sourceforge. I was using the module agrepy and I'm sure that where the bug is. Since I removed the use of this module from my code a few month ago the problem has disapeared. So the python code is fine, there is almost certainly a memory error in agrepy. I make a weak attempt at debugging agrepy but didn't have time to follow through. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 21:25 Message: Logged In: YES user_id=80475 Greg, can you also try this with Py2.3b2+. We're about to release it and need to know if your bug is still present. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:52 Message: Logged In: YES user_id=33168 Gregory, do you still have this problem? Do you believe there is a bug or can we close this report? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-24 16:01 Message: Logged In: YES user_id=33168 After running configure, you must remove all the modules and rebuild them too. This doesn't happen by default. You can also do rm build/*/*.o build/*/*.so to remove the modules. make clean should also work. Have you tried running valgrind, purify, electric fence, or some other memory checker on the code. Perhaps there is a memory problem in the pyagrep module? ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-24 15:46 Message: Logged In: YES user_id=222034 It is hard to reproduce... I realized that the bug may be in a module I use called AGREPY downloadable from http://www.bio.cam.ac.uk/~mw263/pyagrep.html. I tried to reproduce my Python 2.2.2 install with "./configure --with- pydebug" as suggested, but then I get the following error: /usr/greg/soft/linux/python/Python-2.2.2/python rules.py Adding parser accelerators ... Done. Traceback (most recent call last): File "rules.py", line 39, in ? import string, os, agrepy ImportError: /usr/greg/soft/linux/python/Python- 2.2.2/build/lib.linux-i686-2.2/agrepy.so: undefined symbol: Py_InitModule4 [6589 refs] I was mistaken to suspect my use of the "exec" statement, which I replaced with "eval" and the problem still happened. It is not easy to come up with a reasonably small piece of code reproducing the problem! gregory ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-17 13:43 Message: Logged In: YES user_id=33168 Can you post any code which causes the crash, even if it only crashes sometimes? Can you build python with ./configure --with-pydebug and run your program? This may find the problem closer to the cause. ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-17 12:05 Message: Logged In: YES user_id=222034 I forgot to mention that this program is using the "exec()" builtin heavily, and I believe that the crash is related to this. gregory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 From noreply@sourceforge.net Sat Jul 12 03:08:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 19:08:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-669838 ] Seg fault in gcmodule.c Message-ID: Bugs item #669838, was opened at 2003-01-17 12:03 Message generated for change (Settings changed) made by greg7mdp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 Category: Python Interpreter Core Group: Python 2.2.2 >Status: Closed Resolution: None Priority: 5 Submitted By: Gregory Popovitch (greg7mdp) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in gcmodule.c Initial Comment: Using Python 2.2.2 on Linux Redhat 7.2: Python 2.2.2 (#1, Oct 21 2002, 22:19:12) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2 I have a crash which happens somewhat randomly (for example it goes away if I add a print statement somewhere). Here is some gdb info. lnx:0:usr/greg/ib> gdb python2.2 GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (gdb) run rules.py > xx Starting program: /usr/local/bin/python2.2 rules.py > xx [New Thread 1024 (LWP 30182)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 30182)] 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 185 if (op && PyObject_IS_GC(op)) { (gdb) print op $1 = (PyObject *) 0x1000000 (gdb) print data $2 = (void *) 0x0 (gdb) where 20 #0 0x080996f8 in visit_decref (op=0x1000000, data=0x0) at Modules/gcmodule.c:185 #1 0x080c9abb in dict_traverse (op=0x827bc34, visit=0x80996ec , arg=0x0) at Objects/dictobject.c:1589 #2 0x0809897e in collect (young=0x80ee5a0, old=0x80ee5ac) at Modules/gcmodule.c:201 #3 0x08099062 in collect_generations () at Modules/gcmodule.c:518 #4 0x08099576 in _PyObject_GC_New (tp=0x80f8ae0) at Modules/gcmodule.c:879 #5 0x080c7b75 in PyDict_New () at Objects/dictobject.c:161 #6 0x080869d5 in symtable_init () at Python/compile.c:4671 #7 0x08086910 in symtable_build (c=0xbfffea90, n=0x8240e68) at Python/compile.c:4261 #8 0x08084109 in jcompile (n=0x8240e68, filename=0x81f83ec "", base=0x0, flags=0xbfffebe4) at Python/compile.c:4111 #9 0x0808665e in PyNode_CompileFlags (n=0x8240e68, filename=0x81f83ec "", flags=0xbfffebe4) at Python/compile.c:4042 #10 0x080945c7 in Py_CompileStringFlags ( str=0x811f8bc "agrepy(\epreuve photographique\, 22, t, len(t), 0, re[0]) and re[1].search(t)", filename=0x81f83ec "", start=258, flags=0xbfffebe4) at Python/pythonrun.c:1133 #11 0x080cc4cc in builtin_compile (self=0x0, args=0x8241a04) at Python/bltinmodule.c:398 #12 0x080ca7cc in PyCFunction_Call (func=0x8105fb0, arg=0x8241a04, kw=0x0) at Objects/methodobject.c:100 #13 0x08077918 in eval_frame (f=0x81a6fbc) at Python/ceval.c:2014 #14 0x0807892b in PyEval_EvalCodeEx (co=0x81f8750, globals=0x8111ecc, locals=0x0, args=0x82ffe14, argcount=2, kws=0x82ffe1c, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #15 0x0807aa43 in fast_function (func=0x815f754, pp_stack=0xbfffee14, n=2, na=2, nk=0) at Python/ceval.c:3173 #16 0x080779b5 in eval_frame (f=0x82ffc8c) at Python/ceval.c:2034 #17 0x0807892b in PyEval_EvalCodeEx (co=0x81f9768, globals=0x8111ecc, locals=0x0, args=0x81cc34c, argcount=3, kws=0x81cc358, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2595 #18 0x0807aa43 in fast_function (func=0x815f78c, pp_stack=0xbfffef74, n=3, na=3, nk=0) at Python/ceval.c:3173 #19 0x080779b5 in eval_frame (f=0x81cc1f4) at Python/ceval.c:2034 (More stack frames follow...) ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-07-11 22:06 Message: Logged In: YES user_id=222034 Sorry, I had responded earlier via email but it didn't make it in sourceforge. I was using the module agrepy and I'm sure that where the bug is. Since I removed the use of this module from my code a few month ago the problem has disapeared. So the python code is fine, there is almost certainly a memory error in agrepy. I make a weak attempt at debugging agrepy but didn't have time to follow through. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 21:25 Message: Logged In: YES user_id=80475 Greg, can you also try this with Py2.3b2+. We're about to release it and need to know if your bug is still present. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:52 Message: Logged In: YES user_id=33168 Gregory, do you still have this problem? Do you believe there is a bug or can we close this report? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-24 16:01 Message: Logged In: YES user_id=33168 After running configure, you must remove all the modules and rebuild them too. This doesn't happen by default. You can also do rm build/*/*.o build/*/*.so to remove the modules. make clean should also work. Have you tried running valgrind, purify, electric fence, or some other memory checker on the code. Perhaps there is a memory problem in the pyagrep module? ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-24 15:46 Message: Logged In: YES user_id=222034 It is hard to reproduce... I realized that the bug may be in a module I use called AGREPY downloadable from http://www.bio.cam.ac.uk/~mw263/pyagrep.html. I tried to reproduce my Python 2.2.2 install with "./configure --with- pydebug" as suggested, but then I get the following error: /usr/greg/soft/linux/python/Python-2.2.2/python rules.py Adding parser accelerators ... Done. Traceback (most recent call last): File "rules.py", line 39, in ? import string, os, agrepy ImportError: /usr/greg/soft/linux/python/Python- 2.2.2/build/lib.linux-i686-2.2/agrepy.so: undefined symbol: Py_InitModule4 [6589 refs] I was mistaken to suspect my use of the "exec" statement, which I replaced with "eval" and the problem still happened. It is not easy to come up with a reasonably small piece of code reproducing the problem! gregory ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-17 13:43 Message: Logged In: YES user_id=33168 Can you post any code which causes the crash, even if it only crashes sometimes? Can you build python with ./configure --with-pydebug and run your program? This may find the problem closer to the cause. ---------------------------------------------------------------------- Comment By: Gregory Popovitch (greg7mdp) Date: 2003-01-17 12:05 Message: Logged In: YES user_id=222034 I forgot to mention that this program is using the "exec()" builtin heavily, and I believe that the crash is related to this. gregory ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669838&group_id=5470 From noreply@sourceforge.net Sat Jul 12 05:14:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 11 Jul 2003 21:14:38 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-616247 ] More documentation for the imp module Message-ID: Feature Requests item #616247, was opened at 2002-09-29 14:58 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=616247&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jurie Horneman (jhorneman) >Assigned to: Just van Rossum (jvr) Summary: More documentation for the imp module Initial Comment: Not all of the public functions of the imp module appear to be documented (in section 3.21, Python version 2.2). get_frozen_object load_package PY_CODERESOURCE are not documented. Also, the documentation for load_module() can be a bit confusing, partially due to inconsistent use of the word pairs 'tuple' / 'triple' and 'pathname' / 'filename'. (I did not need the abovementioned public functions, but while struggling with this module I noticed them and wondered if the documentation was outdated, or whether they held the key to my success.) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-11 23:14 Message: Logged In: YES user_id=80475 I believe both functions are obsolete and are subsumed by load_module() and find_module(). I don't know about Py_CODERESOURCE (it is MacIntosh specific). Referring to jvr for disposition on the first two and then to Jack for the third. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=616247&group_id=5470 From noreply@sourceforge.net Sat Jul 12 08:36:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 00:36:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect Message-ID: Bugs item #549151, was opened at 2002-04-26 18:04 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: John J Lee (jjlee) Assigned to: Martin v. Löwis (loewis) Summary: urllib2 POSTs on redirect Initial Comment: urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the POST method on redirect, contrary to RFC1945 section 9.3: > 9.3 Redirection 3xx > > This class of status code indicates that further action needs to be > taken by the user agent in order to fulfill the request. The action > required may be carried out by the user agent without interaction > with the user if and only if the method used in the subsequent > request is GET or HEAD. A user agent should never automatically > redirect a request more than 5 times, since such redirections usually > indicate an infinite loop. Can be fixed in HTTPRedirectHandler.http_error_302 by replacing new = Request(newurl, req.get_data()) with new = Request(newurl) so that GET is done on redirect instead of POST. I suppose the limit of 10 in the same function should be changed to 5, also. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-12 09:36 Message: Logged In: YES user_id=21627 Applied rev4 as liburllib.tex 1.50 liburllib2.tex 1.11 urllib2.py 1.53 liburllib.tex 1.40.8.5 liburllib2.tex 1.6.8.4 urllib2.py 1.24.8.9 ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-11 17:45 Message: Logged In: YES user_id=261020 I am just about to upload three patches named *.patch4, which should finally close this bug. The important change is that 301 response to a POST is now automatically redirected. The rest is minor docstring and documentation fixes. They need backporting to 2.2 -- I haven't included separate patches since the changes are trivial. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-11 02:00 Message: Logged In: YES user_id=261020 Note that part of point 2. of my summary of 2003-05-10 is wrong, since 2.2.3 final contains the method urllib2.Request.get_method. I will upload another patch tomorrow, with that corrected. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-09 20:24 Message: Logged In: YES user_id=6380 I've asked on python-dev for help with this, as I expect I won't have time for it before July 17 (cut-off date for 2.3c1). Feel free to assign this to yourself if you want to grab it. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-22 20:33 Message: Logged In: YES user_id=261020 I tested the 301 behaviour of MSIE 5.00 on wine, and Mozilla Firebird 0.6. Both redirect POST to GET (without asking for user confirmation) on a 301 redirect, as expected, so it's probably justified to follow through with the 301 changes we discussed (summarised in my last message, along with a couple of related changes; item 1 has already been done). ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 14:45 Message: Logged In: YES user_id=261020 Sorry for all these tiny updates. Summary of what remains to be done: 1. Apply Guido's patch for urllib.py: guido.txt. The docs are already correct. 2. 301 in response to POST is still not redirected in urllib2. urllib2.py.patch3 fixes that (note patch3, not patch2). It also removes my Request.get_method method (which now seems like overkill, as well as breaking the URL scheme-independence of Request). Also fixes an exception message. 3. liburllib2.tex.patch2 updates the docs to reflect the changes in urllib2.py.patch3, rephrases a note and adds a missing method description. 4. liburllib.tex.patch2: trivial rewording of docs for clarity. 5. Backport above changes to 2.2 bugfix branch. Jeremy in CVS: > The latest changes to the redirect handler couldn't possibly have been > tested, because they did not compute a newurl and failed with a > NameError. The __name__ == "__main__": block has a test for > redirects. Ah. The tests are preceeded by a warning about only working from a particular set of hosts: I mis-remembered, thinking that applied to *all* the tests. Sorry. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-10 02:14 Message: Logged In: YES user_id=261020 OK, I can't test IE, because Windows doesn't have a proper loopback adapter, and my Windows machine is disconnected. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-09 14:46 Message: Logged In: YES user_id=261020 Another test result on browser behaviour with 301 response to POST: lynx 2.8.4rel.1: offers user a choice between POST, GET and cancel Still haven't checked IE. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-07 16:21 Message: Logged In: YES user_id=261020 About 301: I tested Mozilla 1.0.0 and Konqueror 3.1.0 and they both redirect POST to GET without asking for confirmation. Ronald Tschalar tells me he tested Mozilla 1.1 and Netscape 4.7, and got the same result. So, all is as we had thought there (haven't checked IE, though). Side note: After reading another comment of Ronald's (he's the author of the HTTPClient java library), I realise that it would be a good idea to have urllib / urllib2 cache the results of 301 redirections. This shouldn't break anything, since it's just an internal optimisation from one point of view -- but it's also what the RFC says SHOULD happen. I'll file a separate bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-05-06 22:18 Message: Logged In: YES user_id=261020 What, a different urllib2 bug than the two that I uploaded patches for on 2003-04-27? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-05-05 02:27 Message: Logged In: YES user_id=6380 Note that Jeremy found a bug in what's currently checked in for urllib2.py. I'll try to sort this out coming Friday. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 03:33 Message: Logged In: YES user_id=261020 Damn this SF bug system. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 03:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-27 03:31 Message: Logged In: YES user_id=261020 The patch for urllib.py is indeed broken, and I think Guido's patch is correct. I agree with the summary Guido gives, which is also in agreement with our previous discussion. A side issue that occurred to me on re-reading the RFC is whether 301 redirection should be automatic. A 301 is supposed to indicate permanent redirection, so one is supposed to update one's URL when a 301 happens. Redirecting automatically doesn't allow the user of urllib / urllib2 to do that. However, I suppose that since 2.2 *does* redirect automatically (for both urllib and urllib2) it's a bit late to worry about this. The patched urllib2.py is also broken in two ways: 1. It tries to call req.method() -- which doesn't exist -- rather than req.get_method() as it should. print "Must use pychecker.\n"*100 especially when there are no unit tests... Anyway, I decided the new get_method method is unnecessary and the new patch I'll upload in a minute removes it again. 2. 301 response to POST isn't redirected to GET. It should be, as we agreed earlier. Just about to upload revised patches, against 2.3beta CVS. (urllib2.py.patch2, liburllib2.tex.patch2, liburllib.tex.patch2). They need backporting to 2.2 again, too. Bother. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-26 19:21 Message: Logged In: YES user_id=6380 Blech! Reopening. I just stumbled upon the relevant part of RFC 2616, and it suggests to me the following rules when the original request was a POST. I should have made the time for this earlier, but I simply didn't have time. :-( Reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3 Summary: - 307 means repeat the POST to the new URL *after user confirmation* - 303 means do a GET to the new URL - 301 means repeat the POST to the new URL *after user confirmation*, *but* old agents often do a GET instead - 302 may be treated the same as 303 (i.e. GET the new URL) for compatibility with existing practice This suggests to me that *no* automatic repeat of POST requests should ever be done, and that in the case of a 302 or 303 response, a POST should be replaced by a GET; this may also be done for a 301 response -- even though the standard calls that an error, it admits that it is done by old clients. But the new code in urllib.py doesn't seem to do that: it treats 301, 302 and 303 all the same, doing a POST if the original request was a POST (POST is determined by 'data is not None'). And it doesn't redirect on a 307 at all, even though it should do that if the original request was GET. The updated documentation describes the desired behavior for 301,302,303. I think the desired behavior can be obtained by always omitting the data argument in the call to self.open(newurl) in redirect_internal(). Then a handler for 307 could be handled that raises an error if the original request was a POST, and redirects otherwise. I'm attaching a suggested patch to urllib.py (guido.txt). It appears urllib2.py was patched correctly. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-25 10:21 Message: Logged In: YES user_id=80475 Backported to 2.2.3. Closing bug. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-24 17:49 Message: Logged In: YES user_id=6380 Yes, I think that would be a good idea. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-24 17:34 Message: Logged In: YES user_id=80475 Committed as: Lib/urllib.py 1.157 Lib/urllib2.py 1.39 Doc/lib/liburllib.tex 1.47 Doc/lib/liburllib2.tex 1.7 Guido, would you like this backported to 2.2.3? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-04-20 22:44 Message: Logged In: YES user_id=261020 Just noticed that I forgot to upload one of the doc patches on 2003-03-05. Here it is. The patches that need to be applied are the three I uploaded on 2003-03-05 (urllib.py.patch, urllib2.py.patch and liburllib2.tex.patch), and the liburllib.tex.patch I just uploaded. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-04-16 22:35 Message: Logged In: YES user_id=6380 I think this is the right thing to do. Can you check it in? (There are several files -- urllib, urllib2, and its docs). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-04-16 22:27 Message: Logged In: YES user_id=80475 Do you have time to take this one back? My head starts to explode when researching whether this is the right thing to do. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-07 21:57 Message: Logged In: YES user_id=6380 I'll try to work on this. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-03-05 22:03 Message: Logged In: YES user_id=261020 The fix for this was set to go into 2.3, but nothing has happened yet. There were a couple of minor details to be fixed in the patches, so I've done that, and uploaded new patches for urllib2.py, urllib.py, and their documentation files (against current CVS). Well, I'm just about to upload them... Jeremy, can you apply the patches and finally close this one now? Let me know if anything else needs doing. This should actually close another bug on SF, too (if it's still open), which deals with the urllib.py case. I can't find it, though. I did attach a comment to it (before I lost it) that references this bug. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-15 17:22 Message: Logged In: YES user_id=261020 Well, when I carefully read the RFC I came to the conclusion that 301 should be redirected to GET, not POST. I also came to the conclusion that the RFC was slightly ambiguous on this point, so I guess that's why A. Flavell came to the conclusion that 301 should redirect to POST rather than GET. Anyway, clearly the established practice is to redirect 301 as GET, so this is all academic. Assuming he's right about Netscape / IE etc., I suppose I'm happy for 301 to redirect without an exception, since that's what we've agreed to do for 302. Obviously, the docs should say this is contrary to the RFC (as my doc patch says for 302 already). As for urllib.py, I see the problem. 303 should still be added, though, since that poses no problem at all. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-10-11 17:40 Message: Logged In: YES user_id=31392 I'm still uncertain about what to do on 301 responses. As you say, there are two issues to sort out: 1) what method should a POST be redicted to and 2) whether the user should be asked to confirm. There's discussion of this at: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html The page is a bit old, but I don't know if it is out of date. It says that IE5, Netscape 4, and Mozilla 1.0 all redirect a 301 POST to a GET without user confirmation. That seems like a widespread disregard for the spec that we ought to emulate. I agree with your interpretation that urllib2 raise an HTTPError to signal "request confirm" because an HTTPError is also a valid response that the user could interpret. But of urllib, an HTTP error doesn't contain a valid response. The change would make it impossible for the client to do anything if a 301 response is returned from a POST. That seems worse than doing the wrong. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-10 03:27 Message: Logged In: YES user_id=6380 OK, over to jeremy. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-09 23:16 Message: Logged In: YES user_id=261020 Ah. Here it is. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-10-08 20:23 Message: Logged In: YES user_id=6380 Um, I don't see the patch for urllib.py. Perhaps you didn't check the box? Jeremy, let's do this in 2.3, OK? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-08 18:53 Message: Logged In: YES user_id=261020 Guido mentioned that urllib.py should be fixed too. I've attached another patch. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-10-05 19:44 Message: Logged In: YES user_id=261020 Here is a patch for the minor documentation changes required for the patch I uploaded earlier to fix this bug. I've also uploaded a slightly revised patch: I renamed the `method' method to `get_method' for consistency with the other methods of the Request class. The reason this new method is there at all is because the logic that decides whether or not a redirection should take place is defined in terms of the method type (GET/HEAD/POST). urllib2 doesn't support HEAD ATM, but it might in future. OTOH, the Request class is supposed to be generic -- not specific to HTTP -- so perhaps get_method isn't really appropriate. OTOOH, add_data is already documented to only be meaningful for HTTP Requests. I suppose there could be a subclass HTTPRequest, but that's less simple. What do you think is best? I also changed redirect_request to raise an exception instead of returning None (because no other Handler should handle the redirect), and changed its documented return value / exception interface to be consistent with the rest of urllib2. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-23 21:23 Message: Logged In: YES user_id=261020 First, can I underline the fact that there are two issues here: 1. What method should POST be redirected as for a particular 30x response? 2. Should the user be asked to confirm the redirection (which presumably maps onto raising an HTTPError in urllib2)? I think current client implementations go against the RFCs on both these points for 302. Contrastingly, RFC 2616's note on 301 responses (section 10.3.2) implies that only a subset of HTTP/1.0 (not 1.1, note) clients violate the RFCs (1945, 2068, 2616) on point 1 for 301 responses, and I know of no clients that violate the RFCs on point 2 for 301 responses (but I haven't tested). Also, I guess the original intent (for both 301 and 302) was that POSTs represent an action, so it's dangerous in general to redirect them without asking the user: I presume this is why 307 was brought in: 307 POSTs on redirected POST, so the user must be asked: 10.3 Redirection 3xx [...] The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. (and 303 is just meant to have the 'erroneous' 302 behaviour: GET on redirected POST, don't ask the user) So, I agree with Guido that 302 should probably now be treated the way most clients treat it: GET on redirected POST, don't ask the user. As for 301, if it *is* true that only a few HTTP/1.0 clients have misinterpreted the RFCs on 301, we should stick to the safe behaviour indicated by the RFC. As for Guido's first question: A 307 should indeed be redirected as a POST, but it should ask the user first (see 10.3 quote, above). That's what my patch does (the 'return None' in the else clause in redirect_request causes an exception to be raised eventually -- maybe it should just raise it itself). I've attached a revised patch that deals with 302 (and 303) in the 'erroneous' way (again: GET on redirected POST, don't ask the user). I suppose the comment about HTTPRedirectHandler also needs to state that 301 and 307 POST requests are not automatically redirected -- HTTPError is raised in that case. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-06-20 02:57 Message: Logged In: YES user_id=6380 Hm, I thought that 307 should be treated differently than 303. In particular, a 307 response to POST should cause the POST to be redirected. And I'm not sure about what a 301 response to POST should do. (In the mean time I have been convinced that changing POST to GET on 302 is the best thing to do given that most browsers do that. The old urllib.py should be fixed too.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 23:57 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-19 23:56 Message: Logged In: YES user_id=261020 I've attached a patch -- was simpler than I thought. I think this is in compliance with RFC 2616. It's also simple for clients to inherit from HTTPRedirectHandler and override redirect_request if, for example, they know they want all 302 POSTs to be redirected as a GET, which removes the need for mixing redirection code with normal client code even when the server doesn't follow the RFC (if the server expects a 302 POST to be redirected as a GET, for example). Note that I had to add a method, named 'method', to the Request class, for maintainability (it's possible that urllib2 may be able to do methods other than GET and POST in future). Possibly redirect_request should take fewer parameters. John ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-06-06 23:25 Message: Logged In: YES user_id=261020 Oh, I hadn't realised httplib uses HTTP/1.1 now -- and now I check, I see that even RFC 1945 (HTTP/1.0) has a whole set of restrictions on 30x for particular values of x which I missed completely. I guess it should do what Guido suggested -- report an error if a POST is redirected -- until somebody gets time to do it properly. I won't have time for a couple of months, but if nobody has done it by then I'll upload a patch. John ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-06-06 17:09 Message: Logged In: YES user_id=31392 I think you need to review the current HTTP spec -- RFC 2616 -- and look at the section on redirection (10.3). I think urllib2 could improve its handling of redirection, but the behavior you describe from lynx sounds incorrect. I'd be happy to review a patch the implemented the current spec. Also, RFC 2616 removes the recommendation of a 5 redirect limit. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 20:10 Message: Logged In: YES user_id=6380 Fair enough. I'll leve it to Jeremy to review the proposed fix. (Note that he's busy though.) ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-29 18:29 Message: Logged In: YES user_id=261020 I don't see why it shouldn't substitue a GET. That certainly seems to be the standard practice (well, at least that's what lynx does), and in the case of the only site where I've encountered redirects on POST, the redirect URL contains urlencoded stuff, so it clearly expects the user-agent to do a GET. The site would break if this didn't happen, so I guess Netscape and IE must do the same thing. Clearly the RFC *does* allow this, though it doesn't require it (or specify what should happen here in any way other than to say that a POST is not allowed, in fact). Since it's standard practice and allowed by the RFC, I don't think it should be an error. John ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-04-29 02:53 Message: Logged In: YES user_id=6380 Hm, the way I interpret the text you quote, if the original request is a POST, it should probably not substitute a GET but report the error. Assigning to Jeremy since it's his module. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2002-04-28 18:21 Message: Logged In: YES user_id=261020 1. Bug is also in 2.2 branch 2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers: new = Request(newurl, headers=req.headers) 3. I guess 10 should be replaced with 4, not 5. John ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470 From noreply@sourceforge.net Sat Jul 12 13:04:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 05:04:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-770107 ] Type in documentation of resource module Message-ID: Bugs item #770107, was opened at 2003-07-12 14: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=770107&group_id=5470 Category: Documentation Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Max Neunhöffer (neunhoef) Assigned to: Nobody/Anonymous (nobody) Summary: Type in documentation of resource module Initial Comment: In Section 8.15.1 of the Python library reference manual there are two typos, one of them leading to wrong information: RLIMIT_MEMLOC The maximm address space which may be locked in memory. must be: RLIMIT_MEMLOCK The maximum address space which may be locked in memory. The same seems to hold in version 2.3.b2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770107&group_id=5470 From noreply@sourceforge.net Sat Jul 12 13:05:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 05:05:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-770107 ] Typo in documentation of resource module Message-ID: Bugs item #770107, was opened at 2003-07-12 14:04 Message generated for change (Settings changed) made by neunhoef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770107&group_id=5470 Category: Documentation Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Max Neunhöffer (neunhoef) Assigned to: Nobody/Anonymous (nobody) >Summary: Typo in documentation of resource module Initial Comment: In Section 8.15.1 of the Python library reference manual there are two typos, one of them leading to wrong information: RLIMIT_MEMLOC The maximm address space which may be locked in memory. must be: RLIMIT_MEMLOCK The maximum address space which may be locked in memory. The same seems to hold in version 2.3.b2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770107&group_id=5470 From noreply@sourceforge.net Sat Jul 12 13:06:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 05:06:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-770107 ] Typo in documentation of resource module Message-ID: Bugs item #770107, was opened at 2003-07-12 14:04 Message generated for change (Settings changed) made by neunhoef You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770107&group_id=5470 Category: Documentation Group: Python 2.2.3 Status: Open Resolution: None >Priority: 2 Submitted By: Max Neunhöffer (neunhoef) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in documentation of resource module Initial Comment: In Section 8.15.1 of the Python library reference manual there are two typos, one of them leading to wrong information: RLIMIT_MEMLOC The maximm address space which may be locked in memory. must be: RLIMIT_MEMLOCK The maximum address space which may be locked in memory. The same seems to hold in version 2.3.b2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770107&group_id=5470 From noreply@sourceforge.net Sat Jul 12 14:14:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 06:14:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http Message-ID: Bugs item #767111, was opened at 2003-07-07 13:52 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: AttributeError thrown by urllib.open_http Initial Comment: In 2.3b2, looks like an error condition isn't being picked up on line 300 or 301 of urllib.py. The code that triggered this traceback was simply: url = urllib.urlopen(action, data) Traceback (most recent call last): File "autospamrep.py", line 170, in ? current_page = handle_spamcop_page(current_page) File "autospamrep.py", line 140, in handle_spamcop_page url = urllib.urlopen(action, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 78, in urlopen return opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 183, in open return getattr(self, name)(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 308, in open_http return self.http_error(url, fp, errcode, errmsg, headers, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-12 14:14 Message: Logged In: YES user_id=261020 HTTPResponse.read returns '' if its .fp is None, but the backwards-compat HTTP class' .getfile() just returns self.file, which it previously grabbed from HTTPResponse in .getreply(). Wild guess: maybe HTTP.getreply should just do self.file = response rather than self.file = response.fp The object returned by HTTP.getfile() was documented as returning an object supporting .readline() and .readlines(), while HTTPResponse only supports .read(), so that's obviously not the whole solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 06:50 Message: Logged In: YES user_id=80475 What were the values of 'action' and 'data' when the call was made? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 From noreply@sourceforge.net Sat Jul 12 20:02:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 12:02:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-770247 ] Python 2.3/cvs fails to build without-threads Message-ID: Bugs item #770247, was opened at 2003-07-12 21:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770247&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3/cvs fails to build without-threads Initial Comment: Python 2.3/cvs fails to build if Python has been configured with --without-threads, because pystate.c uses "PyThread_get_thread_ident" (see the attached build.log). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770247&group_id=5470 From noreply@sourceforge.net Sat Jul 12 20:04:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 12:04:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-770247 ] Python 2.3/cvs fails to build without-threads Message-ID: Bugs item #770247, was opened at 2003-07-12 21:02 Message generated for change (Comment added) made by marc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770247&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3/cvs fails to build without-threads Initial Comment: Python 2.3/cvs fails to build if Python has been configured with --without-threads, because pystate.c uses "PyThread_get_thread_ident" (see the attached build.log). ---------------------------------------------------------------------- >Comment By: Marc Recht (marc) Date: 2003-07-12 21:04 Message: Logged In: YES user_id=205 This was on NetBSD-current. Maybe the config.log helps, too... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770247&group_id=5470 From noreply@sourceforge.net Sat Jul 12 20:10:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 12:10:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Comment added) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Kurt B. Kaiser (kbk) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-12 19:10 Message: Logged In: YES user_id=819035 Thanks for the instructive comments. Here are some answers: 1) The problems are the following: a) The standard key bindings are the IDLE Classic Windows key bindings, which do not work. - None of the many bindings that use the Alt modifier work, since the Alt (a.k.a. Option) key is used in MacOSX for accents and symbols. b) The IDLE Classic Mac key bindings do not work. - Most of them require the Command key, which for some unknown reason do not seem to work. c) The IDLE Classic Unix key bindings mostly work, but are unsatisfactory. - These bindings replace many "chord" key bindings with emacs style shortcuts, which are frankly unpleasant to use for 99% of people not used to emacs. Also, there are still several of these Unix key bindings that use the Alt modifier, and which thus do not work in MacOSX. In spite of all this, it is the most usable of the 3 default schemes. d) 5 key bindings used by extensions are currently not rebindable: Alt-Key-q, Alt-Key-slash, Alt-Key-2, Alt-Key-x and Key-F5. Since 4 of them use the Alt modifier, they do not work under MacOSX e) Some bits of extend.txt and help.txt are outdated. 2) A slightly awkward workaround to problem 1.b: What I meant was that by replacing Command with Meta in key bindings means that many but far from all Command bindings work. By chance, I discovered that using the Control-Command combination instead of just the Command modifier makes most if not all Meta bindings work. It seems as if Meta really is interpreted as Control-Command, with Command working sometimes. This is not very satisfactory, but it's better than any of the other 3 default bindings. 3) Regarding capitalization: I discovered by accident that Tk keybindings are case sensitive. However, all bindings mentioned by me treat capitals and lowercase letters identically, i.e. when I wrote Command-B, I really meant Command-b, and not Command-Shift-b. I'll take care not make that confusion from now on. 4) Command-b and Control-b: The bindings mentioned in my 2003-07-11 18:48 message are Command bindings. Command-b and Command-f really do move to the beginning and end of words, unlike Control-b and Control-f, which move one character back and one character forward. I have no idea why some these Command bindings work, but the fact is they do. 5) It might be useful to get other MacOSX users to check my findings, since there might quirks with my configuration which I'm not aware of. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 20:43 Message: Logged In: YES user_id=149084 Thank you for reporting the issues with help.txt and extend.txt. I will update these files. You are correct about the renaming, extend.txt has not been updated since the new config system was implemented. I agree it would be nice to set the extension configuration from the configuration dialog. However, we are much too close to release to contemplate doing that for 2.3. The extension feature is intended to incorporate 3rd party features so the enhancement of the config dialog would have to be suitably general. Your problem appears to be down to one thing: none of IDLE's "Classic Mac" Command combinations in your config-keys.def work. If I understand you correctly, you are saying that e.g. replacing "Command-Key-w" by "Meta-Key-w" in config-keys.def causes the <> event to work correctly? Note that Tk is very picky about capitalization. "Command-Key-w" is not the same as "Command-Key-W". Please be sure that your file is correct in this regard. If you can get everything working by doing this, would you please upload the modified version of your config-keys.def and let me know what the remaining problems are, if any. In your messages you have variously said that both "Command-B" and "Ctl-b" keystrokes go to the beginning of a word. Is this correct? And do you really mean "Apple/Shift/b" in the first case? The Ctl-b binding and others like it that you have mentioned in your earlier message are part of a number of default Tk bindings that have not been disabled in IDLE. http://www.tcl.tk/man/tcl8.3/TkCmd/text.htm#M141 Clearly, there may not be complete compatibility with this documentation in the Tk Mac implementation. But that is the origin of the bindings. By the way, the way to customize is not to modify config-keys.def, but to modify your .idlerc/config-keys.cfg or any of the other files in that directory. That is what the config dialog does, and it is quite all right to modify it manually as long as you carefully follow the format. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 19:08 Message: Logged In: YES user_id=819035 The file extend.txt references two files that do not exist: keydefs and config.txt I suppose the former corresponds config-keys.def, while the latter has been split into 3 files: config-main.def, config-extensions.def and config-highlight.def. Is this correct? Looking into config-extensions.def, I can finally see were those non-standard key sequences are defined: [FormatParagraph_cfgBindings] format-paragraph= (...) [AutoExpand_cfgBindings] expand-word= (...) [ZoomHeight_cfgBindings] zoom-height= (...) [ScriptBinding_cfgBindings] run-module= check-module= It would nice if these key bindings for extension modules could be put in the same file as the standard key bindings. Even nicer if the configuration dialog could be used to change all key bindings. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:48 Message: Logged In: YES user_id=819035 Using the original [IDLE Classic Mac] shortcut keys definitions, the only Command shortcuts that do anything are the following: Command-Q: tries to quit X11 instead of IDLE Command-W: closes X11 windows instead of IDLE windows Command-B: go to beginning of word Command-F: go to end of word Command-D: delete next word Command-H: hide X11 Command-M: minimize window Command-,: X11 preferences dialog ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:43 Message: Logged In: YES user_id=819035 Sorry, my confusion. Since I edited my original config-keys.def file, I forgot that the [IDLE Classic Mac] shortcuts used the Command modifier, and not Alt. This confusion is only made in my last message. If you replace "Command" with "Alt" in that message, everything makes sense: """ If I change all keybinding using the Command-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Command, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. """ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 18:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 16:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 13:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 05:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Sun Jul 13 01:41:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 17:41:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http Message-ID: Bugs item #767111, was opened at 2003-07-07 07:52 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: AttributeError thrown by urllib.open_http Initial Comment: In 2.3b2, looks like an error condition isn't being picked up on line 300 or 301 of urllib.py. The code that triggered this traceback was simply: url = urllib.urlopen(action, data) Traceback (most recent call last): File "autospamrep.py", line 170, in ? current_page = handle_spamcop_page(current_page) File "autospamrep.py", line 140, in handle_spamcop_page url = urllib.urlopen(action, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 78, in urlopen return opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 183, in open return getattr(self, name)(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 308, in open_http return self.http_error(url, fp, errcode, errmsg, headers, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-12 08:14 Message: Logged In: YES user_id=261020 HTTPResponse.read returns '' if its .fp is None, but the backwards-compat HTTP class' .getfile() just returns self.file, which it previously grabbed from HTTPResponse in .getreply(). Wild guess: maybe HTTP.getreply should just do self.file = response rather than self.file = response.fp The object returned by HTTP.getfile() was documented as returning an object supporting .readline() and .readlines(), while HTTPResponse only supports .read(), so that's obviously not the whole solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 00:50 Message: Logged In: YES user_id=80475 What were the values of 'action' and 'data' when the call was made? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 From noreply@sourceforge.net Sun Jul 13 01:47:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 17:47:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-770107 ] Typo in documentation of resource module Message-ID: Bugs item #770107, was opened at 2003-07-12 07:04 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770107&group_id=5470 Category: Documentation Group: Python 2.2.3 >Status: Closed >Resolution: Fixed Priority: 2 Submitted By: Max Neunhöffer (neunhoef) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in documentation of resource module Initial Comment: In Section 8.15.1 of the Python library reference manual there are two typos, one of them leading to wrong information: RLIMIT_MEMLOC The maximm address space which may be locked in memory. must be: RLIMIT_MEMLOCK The maximum address space which may be locked in memory. The same seems to hold in version 2.3.b2 ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 19:47 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libresource.tex 1.18 Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770107&group_id=5470 From noreply@sourceforge.net Sun Jul 13 01:56:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 17:56:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-741029 ] HTMLParser -- possible bug in handle_comment Message-ID: Bugs item #741029, was opened at 2003-05-21 05:35 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741029&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Scott Israel (scott_israel) Assigned to: Nobody/Anonymous (nobody) Summary: HTMLParser -- possible bug in handle_comment Initial Comment: >>> import HTMLParser >>> class Parser(HTMLParser.HTMLParser): def __init__(self): HTMLParser.HTMLParser.__init__ (self) def handle_data(self,data): print 'DATA: %s' % data def handle_comment(self,comment): print 'COMMENT: %s' % comment >>> test3='' >>> p=Parser() >>> p.feed(test3) DATA: Is this a bug? ---------------------------------------------------------------------- Comment By: logistix (logistix) Date: 2003-05-21 15:04 Message: Logged In: YES user_id=699438 No, Without the comments, most legacy browsers would display the text "body{dd:00;}" on the rendered webpage. HTML Spec reference is here: http://www.w3.org/TR/html4/present/styles.html#h-14.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=741029&group_id=5470 From noreply@sourceforge.net Sun Jul 13 02:31:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 18:31:52 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-748201 ] time.strptime() should display format and date on error Message-ID: Feature Requests item #748201, was opened at 2003-06-03 09:14 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=748201&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Guettler (guettli) Assigned to: Brett Cannon (bcannon) Summary: time.strptime() should display format and date on error Initial Comment: Hi! It would be very nice if the ValueError of time.strptime() would display the format and the date if there is a mismatch. Up to now (python 2.2.2) the Error looks like this: ValueError: format mismatch It would be nice if it would look like this: format mismatch: str=2002.12.24 format=%Y-%m-%d thomas ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 20:31 Message: Logged In: YES user_id=80475 Making an error message more informative is a worthwhile usability fix since it is only a one line change. Applied as: Lib/_strptime.py 1.21 ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 12:13 Message: Logged In: YES user_id=357491 I will see what I can do. I am not going to touch this, though, until after 2.3 is out since I don't want to risk breaking any code. Besides, strptime is going to get a slight overhaul after 2.3 comes out to clean it up and make it leaner. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-06-30 06:08 Message: Logged In: YES user_id=89016 Maybe time.strptime() should use a subclass of ValueError, with proper attributes. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 01:17 Message: Logged In: YES user_id=80475 Helpful, informative error messages are certainly a step in the right direction. Referrring to Brett for implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=748201&group_id=5470 From noreply@sourceforge.net Sun Jul 13 03:07:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 19:07:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-706546 ] u''.translate not documented Message-ID: Bugs item #706546, was opened at 2003-03-19 16:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706546&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Martijn Pieters (mjpieters) Assigned to: Nobody/Anonymous (nobody) Summary: u''.translate not documented Initial Comment: The behaviour of u''.translate is significantly different from ''.translate, yet the difference is not reflected in the documentation. - ''.translate takes one or two arguments, one a table of 256 characters for the translation target and the other a string containing characters to be removed. - u''.translate only takes on argument, which is a mapping from unicode ordinal to unicode ordinal, ustring or None. See also print u''.translate.__doc__ ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-12 21:07 Message: Logged In: YES user_id=80475 Added the requested clarification. See Doc/lib/libstring.tex 1.51 ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-20 12:53 Message: Logged In: YES user_id=38388 I see. In that case, I'd suggest you provide a patch to fill up the gaps. Thanks. ---------------------------------------------------------------------- Comment By: Martijn Pieters (mjpieters) Date: 2003-03-20 09:26 Message: Logged In: YES user_id=116747 No, the documentation on u''.translate is *not present*. The Python Library Reference makes no mention of a difference. See: http://www.python.org/doc/current/lib/string-methods.html I don't really care how it is of little use, I just need the documentation to be up to date so I don't have to scratch my head why I get this weird error that translate only takes one argument; as it turns out the strings I was calling this on were unicode strings. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-03-20 04:15 Message: Logged In: YES user_id=38388 Isn't the documentation clear enough about the difference ? Note that u.translate() is not really all that useful. You are much better off with writing your own charmap based codec which is not really difficult: just take a look at e.g. cp1251.py. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706546&group_id=5470 From noreply@sourceforge.net Sun Jul 13 03:28:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 12 Jul 2003 19:28:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 05:35 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-12 19:28 Message: Logged In: YES user_id=357491 I uploaded a new version of the patch. Give it a try and see what happens if you could. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-10 10:11 Message: Logged In: YES user_id=357491 Barry says you need to do the following to truly test the patch: - check out the head - make distclean - apply the patch - autoreconf - ./configure --with-pydebug - make test Apparently autoreconf regenerates something for autoconf and that has to be done. Learn something new everyday. Can you give that a shot, Torsten? If that still fails it is going to take some work to figure this one out. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-10 00:58 Message: Logged In: YES user_id=269193 no, sorry, no success! * re-compiled python, as expected the test failed again. * patch -p0 <../tzset4.diff * made a "make distclean" * ./configure again, looked nice, no chached stuff. * make * make test >>> failed again !!! anything i could check to help? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 21:37 Message: Logged In: YES user_id=80475 Tonight, test_time also failed for me and then worked on the next pass. Am using WinME and Py2.3b2+. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-09 11:30 Message: Logged In: YES user_id=269193 sorry, problem! hard drive scambled. i have to re-install python anyway. i will see if the test fails again, and then i try to apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 10:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-30 22:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 19:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 10:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 08:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Sun Jul 13 09:54:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 01:54:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-770465 ] classmethod(classmethod(foo)) -> SystemError Message-ID: Bugs item #770465, was opened at 2003-07-13 18: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=770465&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: classmethod(classmethod(foo)) -> SystemError Initial Comment: Using 2.2.3 or current release22-maint: >>> classmethod(classmethod(None)).__get__(1) Traceback (most recent call last): File "", line 1, in ? SystemError: Objects/classobject.c:2022: bad argument to internal function (thanks to Steve Alexander for the one-line example) This produces the error "classmethod is not callable" in 2.3, but no systemerror - dunno if 2.3 could provide a better error message here. A more realistic example (derived from the code that originally tripped me up): >>> class a: ... def foo(self): ... print "self is", self, type(self) ... foo=classmethod(foo) ... foo=classmethod(foo) ... >>> b=a() >>> b.foo() Traceback (most recent call last): File "", line 1, in ? SystemError: Objects/classobject.c:2022: bad argument to internal function ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770465&group_id=5470 From noreply@sourceforge.net Sun Jul 13 10:45:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 02:45:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-770465 ] classmethod(classmethod(foo)) -> SystemError Message-ID: Bugs item #770465, was opened at 2003-07-13 03:54 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770465&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Nobody/Anonymous (nobody) Summary: classmethod(classmethod(foo)) -> SystemError Initial Comment: Using 2.2.3 or current release22-maint: >>> classmethod(classmethod(None)).__get__(1) Traceback (most recent call last): File "", line 1, in ? SystemError: Objects/classobject.c:2022: bad argument to internal function (thanks to Steve Alexander for the one-line example) This produces the error "classmethod is not callable" in 2.3, but no systemerror - dunno if 2.3 could provide a better error message here. A more realistic example (derived from the code that originally tripped me up): >>> class a: ... def foo(self): ... print "self is", self, type(self) ... foo=classmethod(foo) ... foo=classmethod(foo) ... >>> b=a() >>> b.foo() Traceback (most recent call last): File "", line 1, in ? SystemError: Objects/classobject.c:2022: bad argument to internal function ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 04:45 Message: Logged In: YES user_id=80475 This was fixed in revision 2.63 on Jun 18, 2003 and marked as a backport candidate. See SF bug #753451. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770465&group_id=5470 From noreply@sourceforge.net Sun Jul 13 10:49:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 02:49:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-764560 ] python treats IRIX64 and IRIX as different, but they are the Message-ID: Bugs item #764560, was opened at 2003-07-02 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=764560&group_id=5470 Category: Build Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gordon Lack (gmlack) Assigned to: Martin v. Löwis (loewis) Summary: python treats IRIX64 and IRIX as different, but they are the Initial Comment: Related to bug 216255 (116255?), but this goes deeper, as it refers to the *running* of python rather than just its building. If I build python on an Irix6.5 system (that is new/large) the tag "irix646" is used in the build/temp.* directory (and Lib/plat-*). This has several effects: a) the plat-irix6 directory from the standard distribution is ignored. b) running the tests on an IRIX system after compiling on an IRIX64 one causes it to rebuild everything, as it will look for temp.irix-6.5-2.2 and lib.irix-6.5-2.2 in build/ rather than the temp.irix64-6.5-2.2 and lib.irix64-6.5-2.2 which were actually built. c) running the same executable on a smaller system (a single installation, NFS mounted onto a large number of systems, for which "uname -s" returns IRIX, not IRIX64) will cause it to fail to find the </python2.2/Lib/plat-irix646 directory. (This might also affect 3rd party module installation?). IRIX and IRIX64 are the same when you build n32 binaries (which is what is built by default). Python should treat them the same. It should be possible to *configure* this OS tag at configure time (which would avoid this problem). Also, installing the "plat-irix646" directories under <> rather than <> would remove the need for such a tag in the installed files. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 11:49 Message: Logged In: YES user_id=21627 Thanks for the patch. Committed as configure 1.414 configure.in 1.425 configure 1.279.6.21 configure.in 1.288.6.21 ---------------------------------------------------------------------- Comment By: Gordon Lack (gmlack) Date: 2003-07-11 13:12 Message: Logged In: YES user_id=88015 I thought I had checked the box - I'll try again.... ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 22:47 Message: Logged In: YES user_id=21627 There is no attachment. Can you please check the checkbox? ---------------------------------------------------------------------- Comment By: Gordon Lack (gmlack) Date: 2003-07-09 15:14 Message: Logged In: YES user_id=88015 Ok - to fix this *particular* part of the problem turns out to be simple. (I had tried setting MACHDEP in my environment, but that fails as, if MACHDEP is set, then the configure script does not set ac_sys_system and ac_sys_release so tests on these fail to get done). So, attached is the patch which equates the two. NOTE: There are other build problems. The SGI C linker (and OSF1) uses -rpath not -R, and the extension buuilding scripts don't knwo how to handle this...but I suppose these would be for a different bug report. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-05 18:32 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=105470&aid=764560&group_id=5470 From noreply@sourceforge.net Sun Jul 13 11:12:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 03:12:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-770465 ] classmethod(classmethod(foo)) -> SystemError Message-ID: Bugs item #770465, was opened at 2003-07-13 18:54 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770465&group_id=5470 Category: None >Group: Python 2.2 >Status: Open >Resolution: Accepted Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: classmethod(classmethod(foo)) -> SystemError Initial Comment: Using 2.2.3 or current release22-maint: >>> classmethod(classmethod(None)).__get__(1) Traceback (most recent call last): File "", line 1, in ? SystemError: Objects/classobject.c:2022: bad argument to internal function (thanks to Steve Alexander for the one-line example) This produces the error "classmethod is not callable" in 2.3, but no systemerror - dunno if 2.3 could provide a better error message here. A more realistic example (derived from the code that originally tripped me up): >>> class a: ... def foo(self): ... print "self is", self, type(self) ... foo=classmethod(foo) ... foo=classmethod(foo) ... >>> b=a() >>> b.foo() Traceback (most recent call last): File "", line 1, in ? SystemError: Objects/classobject.c:2022: bad argument to internal function ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-13 20:12 Message: Logged In: YES user_id=29957 Re-opening, assigning to myself to remind me to do the backport. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 19:45 Message: Logged In: YES user_id=80475 This was fixed in revision 2.63 on Jun 18, 2003 and marked as a backport candidate. See SF bug #753451. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770465&group_id=5470 From noreply@sourceforge.net Sun Jul 13 11:15:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 03:15:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-770247 ] Python 2.3/cvs fails to build without-threads Message-ID: Bugs item #770247, was opened at 2003-07-13 05:02 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770247&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3/cvs fails to build without-threads Initial Comment: Python 2.3/cvs fails to build if Python has been configured with --without-threads, because pystate.c uses "PyThread_get_thread_ident" (see the attached build.log). ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-13 20:15 Message: Logged In: YES user_id=29957 On RH9, build doesn't fail, but does give a warning: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/pystate.o Python/pystate.c Python/pystate.c: In function `PyThreadState_New': Python/pystate.c:147: warning: implicit declaration of function `PyThread_get_thread_ident' ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-07-13 05:04 Message: Logged In: YES user_id=205 This was on NetBSD-current. Maybe the config.log helps, too... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770247&group_id=5470 From noreply@sourceforge.net Sun Jul 13 11:42:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 03:42:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-770247 ] Python 2.3/cvs fails to build without-threads Message-ID: Bugs item #770247, was opened at 2003-07-12 21:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770247&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Marc Recht (marc) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.3/cvs fails to build without-threads Initial Comment: Python 2.3/cvs fails to build if Python has been configured with --without-threads, because pystate.c uses "PyThread_get_thread_ident" (see the attached build.log). ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-13 12:42 Message: Logged In: YES user_id=21627 This is fixed in pystate.c 2.29. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-13 12:15 Message: Logged In: YES user_id=29957 On RH9, build doesn't fail, but does give a warning: gcc -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -DPy_BUILD_CORE -o Python/pystate.o Python/pystate.c Python/pystate.c: In function `PyThreadState_New': Python/pystate.c:147: warning: implicit declaration of function `PyThread_get_thread_ident' ---------------------------------------------------------------------- Comment By: Marc Recht (marc) Date: 2003-07-12 21:04 Message: Logged In: YES user_id=205 This was on NetBSD-current. Maybe the config.log helps, too... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770247&group_id=5470 From noreply@sourceforge.net Sun Jul 13 12:05:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 04:05:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-770485 ] cStringIO does not set closed attr Message-ID: Bugs item #770485, was opened at 2003-07-13 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=770485&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bastian Kleineidam (calvin) Assigned to: Nobody/Anonymous (nobody) Summary: cStringIO does not set closed attr Initial Comment: All StringIO() instances have and set the "closed" attribute on close. The cStringIO() instances do not, but I see no reason why they should not have and set a "closed" attribute. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770485&group_id=5470 From noreply@sourceforge.net Sun Jul 13 14:58:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 06:58:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-770465 ] classmethod(classmethod(foo)) -> SystemError Message-ID: Bugs item #770465, was opened at 2003-07-13 18:54 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770465&group_id=5470 Category: None Group: Python 2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: classmethod(classmethod(foo)) -> SystemError Initial Comment: Using 2.2.3 or current release22-maint: >>> classmethod(classmethod(None)).__get__(1) Traceback (most recent call last): File "", line 1, in ? SystemError: Objects/classobject.c:2022: bad argument to internal function (thanks to Steve Alexander for the one-line example) This produces the error "classmethod is not callable" in 2.3, but no systemerror - dunno if 2.3 could provide a better error message here. A more realistic example (derived from the code that originally tripped me up): >>> class a: ... def foo(self): ... print "self is", self, type(self) ... foo=classmethod(foo) ... foo=classmethod(foo) ... >>> b=a() >>> b.foo() Traceback (most recent call last): File "", line 1, in ? SystemError: Objects/classobject.c:2022: bad argument to internal function ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-13 23:58 Message: Logged In: YES user_id=29957 Backported. Thanks for the pointer! (also fixed identical bug in Zope3's ContextMethod) Checking in Objects/funcobject.c; /cvsroot/python/python/dist/src/Objects/funcobject.c,v <-- funcobject.c new revision: 2.50.4.4; previous revision: 2.50.4.3 done Checking in Lib/test/test_descr.py; /cvsroot/python/python/dist/src/Lib/test/test_descr.py,v <-- test_descr.py new revision: 1.113.4.35; previous revision: 1.113.4.34 done ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-13 20:12 Message: Logged In: YES user_id=29957 Re-opening, assigning to myself to remind me to do the backport. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-13 19:45 Message: Logged In: YES user_id=80475 This was fixed in revision 2.63 on Jun 18, 2003 and marked as a backport candidate. See SF bug #753451. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770465&group_id=5470 From noreply@sourceforge.net Sun Jul 13 19:22:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 11:22:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-770601 ] CGIHTTPServer and environment variables (bug + solution) Message-ID: Bugs item #770601, was opened at 2003-07-13 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=770601&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent delft (vincent_delft) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer and environment variables (bug + solution) Initial Comment: The current CGIHTTPserver cannot handle Environment variables. if you have a simple cgi script printing os.environ, you will see that all the "standard" env varaibles are gone. This is because, the script define a temporary variable called "env" and update then ENVIRONMENT via os.environ.update(env). It's perfect. BUT the call to the cgi script is done via the command os.execve(scriptfile, args, env) and should be done via : os.execve(scriptfile, args, os.environ) This way it works correctly; may be an another methode would be better.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770601&group_id=5470 From noreply@sourceforge.net Sun Jul 13 19:32:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 11:32:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-770601 ] CGIHTTPServer and environment variables (bug + solution) Message-ID: Bugs item #770601, was opened at 2003-07-13 20:22 Message generated for change (Settings changed) made by vincent_delft You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770601&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None >Priority: 7 Submitted By: vincent delft (vincent_delft) >Assigned to: Raymond Hettinger (rhettinger) Summary: CGIHTTPServer and environment variables (bug + solution) Initial Comment: The current CGIHTTPserver cannot handle Environment variables. if you have a simple cgi script printing os.environ, you will see that all the "standard" env varaibles are gone. This is because, the script define a temporary variable called "env" and update then ENVIRONMENT via os.environ.update(env). It's perfect. BUT the call to the cgi script is done via the command os.execve(scriptfile, args, env) and should be done via : os.execve(scriptfile, args, os.environ) This way it works correctly; may be an another methode would be better.... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770601&group_id=5470 From noreply@sourceforge.net Sun Jul 13 22:32:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 14:32:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-768698 ] Odd behavior in the file object Message-ID: Bugs item #768698, was opened at 2003-07-09 16:05 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768698&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: David Nemeth (davidnemeth) Assigned to: Nobody/Anonymous (nobody) Summary: Odd behavior in the file object Initial Comment: Hello, I was using Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 to write a file to parse a text file. The file was divided in two parts, so I wrote something like this: file = open("foobar" ,"r") for line in file: #read a few lines break for line in file: read rest of lines A chunk of the middle part of the file ends up missing. Oddly, it's not the section just after the first few lines are read. I've attached an example script and data file which shows this problem on my system (Windows 2000). The workaround I'm using (which works) is : file = open("foobar","r") while 1: line = file.readline() if line is what I want: break for line in file: do stuff Which seems to work ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-07-13 17:32 Message: Logged In: YES user_id=593130 I believe that the file and iteration specs leave reiteration behavior undefined, making this not-a-bug, even if annoying. In any case, this is known behavior. Explanation (from c.l.py postings): a 2.2 file iterator (apparently a separate object from file object itself) reads blocks of the file and then yields a line at a time. When you break, leftover read data in the last block is discarded. In 2.3, I believe file object is its own iterator. Don't know if it fixed this wart. In any case, perhaps you could close this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768698&group_id=5470 From noreply@sourceforge.net Mon Jul 14 07:57:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 13 Jul 2003 23:57:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-770601 ] CGIHTTPServer and environment variables (bug + solution) Message-ID: Bugs item #770601, was opened at 2003-07-13 13:22 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770601&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed >Resolution: Accepted Priority: 7 Submitted By: vincent delft (vincent_delft) Assigned to: Raymond Hettinger (rhettinger) Summary: CGIHTTPServer and environment variables (bug + solution) Initial Comment: The current CGIHTTPserver cannot handle Environment variables. if you have a simple cgi script printing os.environ, you will see that all the "standard" env varaibles are gone. This is because, the script define a temporary variable called "env" and update then ENVIRONMENT via os.environ.update(env). It's perfect. BUT the call to the cgi script is done via the command os.execve(scriptfile, args, env) and should be done via : os.execve(scriptfile, args, os.environ) This way it works correctly; may be an another methode would be better.... ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-14 01:57 Message: Logged In: YES user_id=80475 See Lib/CGIHTTPServer.py 1.32 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770601&group_id=5470 From noreply@sourceforge.net Mon Jul 14 09:16:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 01:16:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-738090 ] Section 13.3: htmllib.HTMLParser constructor definition amen Message-ID: Bugs item #738090, was opened at 2003-05-15 02:00 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738090&group_id=5470 Category: Documentation Group: Python 2.2.2 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: K. K. Woo (kkwoo) Assigned to: Nobody/Anonymous (nobody) Summary: Section 13.3: htmllib.HTMLParser constructor definition amen Initial Comment: Hi, In section 13.3, the htmllib.HTMLParser constructor description says: class HTMLParser(formatter) I was unable to understand that "formatter" mentioned above referred to something from section 12.1 ("formatter - generic output formatting"). Consequently, I didn't understand how to use the htmllib.HTMLParser base class until I searched on google, and found an example at http://www.tummy.com/python/Examples/showhrefs.txt (link valid as at 15-May-2003). May I suggest adding a cross-reference to section 12.1 in the "See Also: " section of 13.3? Regarding how to improve this section, I'm open to suggestion. Regards, Kevin ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-14 03:16 Message: Logged In: YES user_id=80475 Done. See Doc/lib/libhtmllib.tex 1.26. Thanks for the suggestion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=738090&group_id=5470 From noreply@sourceforge.net Mon Jul 14 09:27:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 01:27:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-702775 ] dumbdbm __del__ bug Message-ID: Bugs item #702775, was opened at 2003-03-13 01:27 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jane Austine (janeaustine50) >Assigned to: Tim Peters (tim_one) Summary: dumbdbm __del__ bug Initial Comment: I used shelve.py and it falls back on dumbdbm when no possible alternatives are found on the system. I found this error, which is recurrent and deterministic: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'error'" in > ignored The problem seems to reside in the __del__ of dumbdbm._Database: class _Database: ... def __del__(self): if self._index is not None: self._commit() ... def _commit(self): try: _os.unlink(self._bakfile) except _os.error: pass try: _os.rename(self._dirfile, self._bakfile) except _os.error: pass f = _open(self._dirfile, 'w', self._mode) for key, (pos, siz) in self._index.items(): f.write("%s, (%s, %s)\n" % (`key`, `pos`, `siz`)) f.close() My investigation showed that the error was from _commit. When it was called, _os or _open was both None. And the exception catch didn't work quite safely cause its in the "except" clause. The reason I suspect is when the time that _Database.__del__ was called the os module(which is imported as _os) is already removed out. I changed the code as: def _commit(self): global _os if _os is None: import os as _os import __builtin__ _open = __builtin__.open try: _os.unlink(self._bakfile) except _os.error: pass try: _os.rename(self._dirfile, self._bakfile) except _os.error: pass ...... Now it works without any problems, AFAIK. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-14 03:27 Message: Logged In: YES user_id=80475 Tim, is this what you just fixed? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-08 16:45 Message: Logged In: YES user_id=357491 OK, so according to Tim all the accessing of _os should be removed and instead call instance or class attributes that are storing what __del__ is going to need when it is cleaning up by calling them off of self since the namespace might be in the process of being cleared. Right? So ``_os.unlink(self._bakfile)`` should be something more like ``self._delattrs['unlink'](self._bakfile)`` where self._delattrs stores everything __del__ is going to need. Or should it just store a reference to the os module at self._os since that might be a little cleaner looking? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-25 23:09 Message: Logged In: YES user_id=31435 Neal, this is actually a common problem in __del__ methods, and the OP's analysis is on target. When Python is shutting down, it tries to tear down module dicts in a safe-as-possible order, but modules are full of reference cycles and there is no *wholly* safe order. In general, a __del__ method should never reference globals because of this. The usual solution can be seen in tempfile.py: store the global objects __del__ will need as class attributes when the class is created, and refer to these bindings in __del__ via self.attrname (ClassName.attrname is also no good, because it refers to the global ClassName! that may also become None). Reimporting a module instead may not be effective (if it's in a partially torn-doiwn state but its name is still a key in sys.modules, importing again will just retrieve the partially torn-down module object). The class-attr trick is robust. ---------------------------------------------------------------------- Comment By: Jane Austine (janeaustine50) Date: 2003-03-25 23:08 Message: Logged In: YES user_id=732903 Tested on linux and windows xp with Python2.2.2 and Python2.3a2. ---------------------------------------------------------------------- Comment By: Jane Austine (janeaustine50) Date: 2003-03-25 23:04 Message: Logged In: YES user_id=732903 Run the main.py in Python 2.3+ putting the two files in the same place. For Python 2.2+, put the two files in the same package and make a new file that imports main.py and run it as follows: ======= from import main ======= ---------------------------------------------------------------------- Comment By: Jane Austine (janeaustine50) Date: 2003-03-25 22:55 Message: Logged In: YES user_id=732903 A test case that triggers this problem: #foobar.py def open(filename, flag='c'): import dumbdbm return dumbdbm.open(filename,flag) c=open('test.dbm') #main.py import foobar $ python main.py >>> Exception exceptions.TypeError: "'NoneType' object is not callable" in > ignored ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 20:06 Message: Logged In: YES user_id=33168 Can you provide a test case which triggers this problem? I can't see how _os becomes None. Also I would like to add a test. Thanks. ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2003-03-13 12:02 Message: Logged In: YES user_id=116941 see the thread at http://groups.google.com/groups? selm=ba1e306f.0303111337.72a696c7% 40posting.google.com , esp. by my name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470 From noreply@sourceforge.net Mon Jul 14 13:54:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 05:54:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-768698 ] Odd behavior in the file object Message-ID: Bugs item #768698, was opened at 2003-07-09 20:05 Message generated for change (Comment added) made by davidnemeth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768698&group_id=5470 Category: Python Library Group: Python 2.2.2 >Status: Closed Resolution: None Priority: 5 Submitted By: David Nemeth (davidnemeth) Assigned to: Nobody/Anonymous (nobody) Summary: Odd behavior in the file object Initial Comment: Hello, I was using Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 to write a file to parse a text file. The file was divided in two parts, so I wrote something like this: file = open("foobar" ,"r") for line in file: #read a few lines break for line in file: read rest of lines A chunk of the middle part of the file ends up missing. Oddly, it's not the section just after the first few lines are read. I've attached an example script and data file which shows this problem on my system (Windows 2000). The workaround I'm using (which works) is : file = open("foobar","r") while 1: line = file.readline() if line is what I want: break for line in file: do stuff Which seems to work ---------------------------------------------------------------------- >Comment By: David Nemeth (davidnemeth) Date: 2003-07-14 12:54 Message: Logged In: YES user_id=819391 I have closed this item, but it would be nice to see the Python behave in a less surprising fashion in future releases. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-07-13 21:32 Message: Logged In: YES user_id=593130 I believe that the file and iteration specs leave reiteration behavior undefined, making this not-a-bug, even if annoying. In any case, this is known behavior. Explanation (from c.l.py postings): a 2.2 file iterator (apparently a separate object from file object itself) reads blocks of the file and then yields a line at a time. When you break, leftover read data in the last block is discarded. In 2.3, I believe file object is its own iterator. Don't know if it fixed this wart. In any case, perhaps you could close this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768698&group_id=5470 From noreply@sourceforge.net Mon Jul 14 16:07:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 08:07:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-770997 ] memory leak in pickle/cPickle [2.2.3] Message-ID: Bugs item #770997, was opened at 2003-07-14 10: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=770997&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael McCandless (mikemccand) Assigned to: Nobody/Anonymous (nobody) Summary: memory leak in pickle/cPickle [2.2.3] Initial Comment: Smallest case I could come up with: import cPickle import random while 1: s = str(random.randint(1000000, 9999999)) a = cPickle.dumps(s) cPickle.loads(a) The leak happens in these cases: * Python 2.2.2 on FreeBSD 5.0. * Python 2.2.3 on WinXP. * Whether you use pickle or cPickle. The leak does NOT happen: * With Python 2.3b2 on FreeBSD 5.0 (maybe this is a dup of a bug fixed on 2.3b2 -- can we back-port the fix?) * If you use binary pickling (change to "a = cPickle.dumps(s, 1)" instead). * If you only call "dumps" or only call "loads"; somehow, it takes both to leak. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=770997&group_id=5470 From noreply@sourceforge.net Mon Jul 14 16:15:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 08:15:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-702775 ] dumbdbm __del__ bug Message-ID: Bugs item #702775, was opened at 2003-03-13 01:27 Message generated for change (Settings changed) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jane Austine (janeaustine50) Assigned to: Tim Peters (tim_one) Summary: dumbdbm __del__ bug Initial Comment: I used shelve.py and it falls back on dumbdbm when no possible alternatives are found on the system. I found this error, which is recurrent and deterministic: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'error'" in > ignored The problem seems to reside in the __del__ of dumbdbm._Database: class _Database: ... def __del__(self): if self._index is not None: self._commit() ... def _commit(self): try: _os.unlink(self._bakfile) except _os.error: pass try: _os.rename(self._dirfile, self._bakfile) except _os.error: pass f = _open(self._dirfile, 'w', self._mode) for key, (pos, siz) in self._index.items(): f.write("%s, (%s, %s)\n" % (`key`, `pos`, `siz`)) f.close() My investigation showed that the error was from _commit. When it was called, _os or _open was both None. And the exception catch didn't work quite safely cause its in the "except" clause. The reason I suspect is when the time that _Database.__del__ was called the os module(which is imported as _os) is already removed out. I changed the code as: def _commit(self): global _os if _os is None: import os as _os import __builtin__ _open = __builtin__.open try: _os.unlink(self._bakfile) except _os.error: pass try: _os.rename(self._dirfile, self._bakfile) except _os.error: pass ...... Now it works without any problems, AFAIK. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-14 11:15 Message: Logged In: YES user_id=31435 Raymond, yes, and thanks for the reminder. This is fixed in current CVS, via the approach I sketched in an comment on this report. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-14 04:27 Message: Logged In: YES user_id=80475 Tim, is this what you just fixed? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-06-08 17:45 Message: Logged In: YES user_id=357491 OK, so according to Tim all the accessing of _os should be removed and instead call instance or class attributes that are storing what __del__ is going to need when it is cleaning up by calling them off of self since the namespace might be in the process of being cleared. Right? So ``_os.unlink(self._bakfile)`` should be something more like ``self._delattrs['unlink'](self._bakfile)`` where self._delattrs stores everything __del__ is going to need. Or should it just store a reference to the os module at self._os since that might be a little cleaner looking? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-03-25 23:09 Message: Logged In: YES user_id=31435 Neal, this is actually a common problem in __del__ methods, and the OP's analysis is on target. When Python is shutting down, it tries to tear down module dicts in a safe-as-possible order, but modules are full of reference cycles and there is no *wholly* safe order. In general, a __del__ method should never reference globals because of this. The usual solution can be seen in tempfile.py: store the global objects __del__ will need as class attributes when the class is created, and refer to these bindings in __del__ via self.attrname (ClassName.attrname is also no good, because it refers to the global ClassName! that may also become None). Reimporting a module instead may not be effective (if it's in a partially torn-doiwn state but its name is still a key in sys.modules, importing again will just retrieve the partially torn-down module object). The class-attr trick is robust. ---------------------------------------------------------------------- Comment By: Jane Austine (janeaustine50) Date: 2003-03-25 23:08 Message: Logged In: YES user_id=732903 Tested on linux and windows xp with Python2.2.2 and Python2.3a2. ---------------------------------------------------------------------- Comment By: Jane Austine (janeaustine50) Date: 2003-03-25 23:04 Message: Logged In: YES user_id=732903 Run the main.py in Python 2.3+ putting the two files in the same place. For Python 2.2+, put the two files in the same package and make a new file that imports main.py and run it as follows: ======= from import main ======= ---------------------------------------------------------------------- Comment By: Jane Austine (janeaustine50) Date: 2003-03-25 22:55 Message: Logged In: YES user_id=732903 A test case that triggers this problem: #foobar.py def open(filename, flag='c'): import dumbdbm return dumbdbm.open(filename,flag) c=open('test.dbm') #main.py import foobar $ python main.py >>> Exception exceptions.TypeError: "'NoneType' object is not callable" in > ignored ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-03-18 20:06 Message: Logged In: YES user_id=33168 Can you provide a test case which triggers this problem? I can't see how _os becomes None. Also I would like to add a test. Thanks. ---------------------------------------------------------------------- Comment By: June Kim (juneaftn) Date: 2003-03-13 12:02 Message: Logged In: YES user_id=116941 see the thread at http://groups.google.com/groups? selm=ba1e306f.0303111337.72a696c7% 40posting.google.com , esp. by my name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=702775&group_id=5470 From noreply@sourceforge.net Mon Jul 14 16:48:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 08:48:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-771018 ] Dead link in library docs Message-ID: Bugs item #771018, was opened at 2003-07-14 08: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=771018&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Peter Scott (sketerpot) Assigned to: Nobody/Anonymous (nobody) Summary: Dead link in library docs Initial Comment: In the robotparser module docs there is a dead link to . This should be changed to . -Peter ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771018&group_id=5470 From noreply@sourceforge.net Mon Jul 14 17:54:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 09:54:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-768698 ] Odd behavior in the file object Message-ID: Bugs item #768698, was opened at 2003-07-09 16:05 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768698&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Closed Resolution: None Priority: 5 Submitted By: David Nemeth (davidnemeth) Assigned to: Nobody/Anonymous (nobody) Summary: Odd behavior in the file object Initial Comment: Hello, I was using Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 to write a file to parse a text file. The file was divided in two parts, so I wrote something like this: file = open("foobar" ,"r") for line in file: #read a few lines break for line in file: read rest of lines A chunk of the middle part of the file ends up missing. Oddly, it's not the section just after the first few lines are read. I've attached an example script and data file which shows this problem on my system (Windows 2000). The workaround I'm using (which works) is : file = open("foobar","r") while 1: line = file.readline() if line is what I want: break for line in file: do stuff Which seems to work ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-07-14 12:54 Message: Logged In: YES user_id=593130 Agreed. I recommend you check behavior of 2.3 (due by end of month - now in final bug fix stage) and raise issue on comp.lang.python if not satifactorily changed. ---------------------------------------------------------------------- Comment By: David Nemeth (davidnemeth) Date: 2003-07-14 08:54 Message: Logged In: YES user_id=819391 I have closed this item, but it would be nice to see the Python behave in a less surprising fashion in future releases. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-07-13 17:32 Message: Logged In: YES user_id=593130 I believe that the file and iteration specs leave reiteration behavior undefined, making this not-a-bug, even if annoying. In any case, this is known behavior. Explanation (from c.l.py postings): a 2.2 file iterator (apparently a separate object from file object itself) reads blocks of the file and then yields a line at a time. When you break, leftover read data in the last block is discarded. In 2.3, I believe file object is its own iterator. Don't know if it fixed this wart. In any case, perhaps you could close this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768698&group_id=5470 From noreply@sourceforge.net Mon Jul 14 18:03:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 10:03:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-769406 ] Droplets aren't always recognized as apps in MacPython 2.3b2 Message-ID: Bugs item #769406, was opened at 2003-07-11 02:21 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769406&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Russell Owen (reowen) >Assigned to: Just van Rossum (jvr) Summary: Droplets aren't always recognized as apps in MacPython 2.3b2 Initial Comment: I am using MacPython 2.3b2 (installed via the 2.3b2-2 binary installer) on MacOS 10.2.3. I turned zappycfiles.py (from the Mac directory of the 2.3b2 source distribution, which I also have) into a drag-and-drop applet by dragging onto BuildApplet. On the whole it works fine (though no console for feedback and I've not figured out how to get one), but I am having two problems that are almost certainly caused by the same underlying problem: - The Dock does not acknowledge that it's an application. I cannot drag it into the usual app area of the dock. - DragThing (4.6.1, the current version) seems to agree with the Dock. It will not let me drag stuff onto it (even with "Check file types during drags" unchecked). Obviously more of an annoyance than a crisis, but I hope worth fixing. ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-14 19:03 Message: Logged In: YES user_id=92689 This has been fixed in CVS (it was a bug in bundlebuilder.py). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769406&group_id=5470 From noreply@sourceforge.net Mon Jul 14 18:07:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 10:07:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-771018 ] Dead link in library docs Message-ID: Bugs item #771018, was opened at 2003-07-14 10:48 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771018&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Peter Scott (sketerpot) >Assigned to: Skip Montanaro (montanaro) Summary: Dead link in library docs Initial Comment: In the robotparser module docs there is a dead link to . This should be changed to . -Peter ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-14 12:07 Message: Logged In: YES user_id=44345 Thanks. Fixed in both the 2.3 and 2.2.x branches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771018&group_id=5470 From noreply@sourceforge.net Mon Jul 14 18:32:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 10:32:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-771097 ] frozen programs fail due to implicit import of "warnings" Message-ID: Bugs item #771097, was opened at 2003-07-14 11: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=771097&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: frozen programs fail due to implicit import of "warnings" Initial Comment: With Python 2.3b2, pythonrun.c now imports the "warnings" module at startup, which causes problems with freezing programs like py2exe, cx_Freeze and Installer The main reason there is a problem is because this takes place during Py_Initialize() so there is no way of overriding the import so that it can find a copy of the warnings module in anything but the filesystem. Is there any way of getting around this? What's worse is that warnings.py imports a raft of other modules (14 others which I can list if necesary) and so the workaround of simply copying the needed files is unwieldy. This is somewhat related to bug 683658. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771097&group_id=5470 From noreply@sourceforge.net Mon Jul 14 19:02:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 11:02:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-771097 ] frozen programs fail due to implicit import of "warnings" Message-ID: Bugs item #771097, was opened at 2003-07-14 11:32 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771097&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: frozen programs fail due to implicit import of "warnings" Initial Comment: With Python 2.3b2, pythonrun.c now imports the "warnings" module at startup, which causes problems with freezing programs like py2exe, cx_Freeze and Installer The main reason there is a problem is because this takes place during Py_Initialize() so there is no way of overriding the import so that it can find a copy of the warnings module in anything but the filesystem. Is there any way of getting around this? What's worse is that warnings.py imports a raft of other modules (14 others which I can list if necesary) and so the workaround of simply copying the needed files is unwieldy. This is somewhat related to bug 683658. ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2003-07-14 12:02 Message: Logged In: YES user_id=619560 In current CVS (revision 2.193 of dist/src/Python/pythonrun.c) at line 193 there is this line PyModule_WarningsModule = PyImport_ImportModule("warnings"); There is no check afterward for any errors. Couldn't a PyErr_Clear() be done so that further statements don't fail because the import of warnings failed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771097&group_id=5470 From noreply@sourceforge.net Mon Jul 14 21:28:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 13:28:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Comment added) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Kurt B. Kaiser (kbk) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 20:28 Message: Logged In: YES user_id=819035 Proposal for new key binding scheme =================================== Problem ------- Due to several reasons discussed in my previous messages, the 3 available key binding schemes for IDLE in MacOSX are not satisfactory for various reasons, the main one being that the Alt/Option modifier is preempted by MacOSX for accented characters and symbols, and the Command/Apple modifier is preempted by X11 for several shortcuts. Considering that IDLE is supposed to be a tool for beginners as well as for more advanced programmers, the key binding scheme for Windows (which is currently the default scheme) also has a few problems. Although all shortcuts in the [IDLE Classic Windows] key binding scheme seem to work, they use an inconsistent mix of modifier keys that hinders learning and makes it difficult to use in platforms where modifier keys work differently. Most of these shortcuts use the Control and Alt modifiers, but some shortcuts use 2 or more modifiers or a third modifier: Control modifier: close-all-windows= Alt/Meta modifier: close-window= Shift modifier: python-context-help= Several modifiers: redo= save-copy-of-window-as-file= Proposal -------- I propose to use a new key binding scheme that uses one single modifier key for all shortcuts in order to increase learnability and portability. The Control modifier is the natural choice for the standard modifier, since unlike the Alt, Command or Windows modifiers it is not usually used for standard OS shortcuts. I am attaching to this message my ~/.idlerc/config-keys.cfg file containing the bindings for this scheme, which I have tentatively named [IDLE Modern]. My hope is to have this scheme become one of the additional schemes shipped with IDLE, and perhaps even replace the [IDLE Classic Windows] scheme as the default scheme for IDLE on all platforms. Rationale --------- I tried to preserve most bindings that have become common in Mac, Windows and Linux applications, and change non-standard bindings to standard. I have also changed all bindings that use a modifier different from Control, sometimes using a similar binding (e.g. instead of for the <> virtual event), sometimes using a completely different binding. I strived to use only alphabetical keys, numerical keys and function keys, since other characters tend to shift according to which keyboard layout one is using. For instance, in the Portuguese keyboard layout the bracket characters have to accessed using a special modifier key, labeled AltGr (for Alt Graphics) together with a numeric key (AltGr-Key-7 and AltGr-Key-8), while the slash character has to be written using Shift-Key-7. This means that the standard bindings for the <>, <> and <> virtual events are difficult if not impossible to access with a Portuguese keyboard layout. One possible solution, which I chose many years ago, is to memorize the American keyboard layout and use that layout for all programming and command-line work, regardless of the actual labels on your keys. Although not really that difficult, this is a step that most people will understandably refuse to take. A more acceptable solution is to avoid using non-alphanumeric characters, which tend to vary a lot more from one layout to the other. I also tried to bind semantically similar virtual events to neighbouring keys, as is already the case with the standard clipboard shortcuts, which occupy 3 neighbouring keys in the same row (x, c and v). For instance, all find commands are placed sequentially in the same row (f, g, h, j and k). All save commands are placed in neighbouring keys (s, e and r). The dedent and indent events are moved to the same row as 4 other events that affect a region, like comment and uncomment (numeric keys row, 1 to 9), along with some other events associated with tabs. Finally, 2 of the most used virtual events, <> and <>, are now bound to and , which should be much more obvious than and . The old bindings are hard to understand unless you have a history of Emacs ab^H^Huse, and are not as intuitive as using the arrows with a modifier key. Extension bindings ------------------ The key bindings for virtual events belonging to IDLE extensions are currently defined in config-extensions.def and are not customizable directly from IDLE. Since 4 of these virtual events currently use the Alt modifier, they conflict with the above rationale of using one single modifier key for all shortcuts, viz. the Control key. I propose to expand these currents shortcuts with another key bindings that fits in with the proposed [IDLE Modern] scheme: format-paragraph= expand-word= zoom-height= run-module= # unchanged check-module= Binding changes --------------- Comparison of [IDLE Modern] bindings to [IDLE Classic Windows] bindings: a) Identical bindings: beginning-of-line= close-all-windows= # modifier-q is a standard binding for 'quit' in Mac (increasingly used in Windows) copy= # modifier-c is a standard binding 'copy' in Windows and Mac cut= # modifier-x is a standard binding 'cut' in Windows and Mac do-nothing= end-of-file= find= # modifier-f is a standard binding for 'find' in Windows and Mac newline-and-indent= open-new-window= # modifier-n is a standard binding for 'new' in Windows and Mac open-window-from-file= # modifier-o is a standard binding for 'open' in Windows and Mac paste= # modifier-v is a standard binding for 'paste' in Windows and Mac print-window= # modifier-p is a standard binding for 'print' in Windows and Mac python-docs= remove-selection= replace= # modifier-h is a standard binding for 'replace' in Windows and Mac save-window= # modifier-s is a standard binding for 'save' in Windows and Mac select-all= # modifier-a is a standard binding for 'select-all' in Windows and Mac smart-backspace= smart-indent= undo= # modifier-z is a standard binding for 'undo' in Windows and Mac view-restart= b) Similar bindings (Alt or Meta modifier replaced with Control modifier): comment-region= open-module= uncomment-region= tabify-region= untabify-region= c) Changed bindings: center-insert= change-indentwidth= close-window= # modifier-w is a standard binding for 'close-window' in Mac (increasingly used in Windows) dedent-region= find-again= # modifier-g is a standard binding for 'find-again' in Windows and Mac find-in-files= find-selection= goto-line= # modifier-l is a common but not standard binding for 'goto-line' in Windows and Mac history-next= history-previous= indent-region= interrupt-execution= open-class-browser= plain-newline-and-indent= python-context-help= redo= # modifier-y is a common but not standard binding for 'redo' in Windows and Mac restart-shell= save-copy-of-window-as-file= save-window-as-file= toggle-auto-coloring= toggle-tabs= Bindings ordered by key ----------------------- smart-backspace= remove-selection= beginning-of-line= newline-and-indent= smart-indent= python-docs= view-restart= restart-shell= python-context-help= do-nothing= history-previous= history-next= dedent-region= indent-region= comment-region= uncomment-region= tabify-region= untabify-region= change-indentwidth= toggle-tabs= toggle-auto-coloring= select-all= open-class-browser= copy= end-of-file= save-window-as-file= find= find-again= replace= interrupt-execution= find-selection= find-in-files= goto-line= open-module= open-new-window= open-window-from-file= print-window= close-all-windows= save-copy-of-window-as-file= save-window= center-insert= plain-newline-and-indent= paste= close-window= cut= redo= undo= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-12 19:10 Message: Logged In: YES user_id=819035 Thanks for the instructive comments. Here are some answers: 1) The problems are the following: a) The standard key bindings are the IDLE Classic Windows key bindings, which do not work. - None of the many bindings that use the Alt modifier work, since the Alt (a.k.a. Option) key is used in MacOSX for accents and symbols. b) The IDLE Classic Mac key bindings do not work. - Most of them require the Command key, which for some unknown reason do not seem to work. c) The IDLE Classic Unix key bindings mostly work, but are unsatisfactory. - These bindings replace many "chord" key bindings with emacs style shortcuts, which are frankly unpleasant to use for 99% of people not used to emacs. Also, there are still several of these Unix key bindings that use the Alt modifier, and which thus do not work in MacOSX. In spite of all this, it is the most usable of the 3 default schemes. d) 5 key bindings used by extensions are currently not rebindable: Alt-Key-q, Alt-Key-slash, Alt-Key-2, Alt-Key-x and Key-F5. Since 4 of them use the Alt modifier, they do not work under MacOSX e) Some bits of extend.txt and help.txt are outdated. 2) A slightly awkward workaround to problem 1.b: What I meant was that by replacing Command with Meta in key bindings means that many but far from all Command bindings work. By chance, I discovered that using the Control-Command combination instead of just the Command modifier makes most if not all Meta bindings work. It seems as if Meta really is interpreted as Control-Command, with Command working sometimes. This is not very satisfactory, but it's better than any of the other 3 default bindings. 3) Regarding capitalization: I discovered by accident that Tk keybindings are case sensitive. However, all bindings mentioned by me treat capitals and lowercase letters identically, i.e. when I wrote Command-B, I really meant Command-b, and not Command-Shift-b. I'll take care not make that confusion from now on. 4) Command-b and Control-b: The bindings mentioned in my 2003-07-11 18:48 message are Command bindings. Command-b and Command-f really do move to the beginning and end of words, unlike Control-b and Control-f, which move one character back and one character forward. I have no idea why some these Command bindings work, but the fact is they do. 5) It might be useful to get other MacOSX users to check my findings, since there might quirks with my configuration which I'm not aware of. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 20:43 Message: Logged In: YES user_id=149084 Thank you for reporting the issues with help.txt and extend.txt. I will update these files. You are correct about the renaming, extend.txt has not been updated since the new config system was implemented. I agree it would be nice to set the extension configuration from the configuration dialog. However, we are much too close to release to contemplate doing that for 2.3. The extension feature is intended to incorporate 3rd party features so the enhancement of the config dialog would have to be suitably general. Your problem appears to be down to one thing: none of IDLE's "Classic Mac" Command combinations in your config-keys.def work. If I understand you correctly, you are saying that e.g. replacing "Command-Key-w" by "Meta-Key-w" in config-keys.def causes the <> event to work correctly? Note that Tk is very picky about capitalization. "Command-Key-w" is not the same as "Command-Key-W". Please be sure that your file is correct in this regard. If you can get everything working by doing this, would you please upload the modified version of your config-keys.def and let me know what the remaining problems are, if any. In your messages you have variously said that both "Command-B" and "Ctl-b" keystrokes go to the beginning of a word. Is this correct? And do you really mean "Apple/Shift/b" in the first case? The Ctl-b binding and others like it that you have mentioned in your earlier message are part of a number of default Tk bindings that have not been disabled in IDLE. http://www.tcl.tk/man/tcl8.3/TkCmd/text.htm#M141 Clearly, there may not be complete compatibility with this documentation in the Tk Mac implementation. But that is the origin of the bindings. By the way, the way to customize is not to modify config-keys.def, but to modify your .idlerc/config-keys.cfg or any of the other files in that directory. That is what the config dialog does, and it is quite all right to modify it manually as long as you carefully follow the format. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 19:08 Message: Logged In: YES user_id=819035 The file extend.txt references two files that do not exist: keydefs and config.txt I suppose the former corresponds config-keys.def, while the latter has been split into 3 files: config-main.def, config-extensions.def and config-highlight.def. Is this correct? Looking into config-extensions.def, I can finally see were those non-standard key sequences are defined: [FormatParagraph_cfgBindings] format-paragraph= (...) [AutoExpand_cfgBindings] expand-word= (...) [ZoomHeight_cfgBindings] zoom-height= (...) [ScriptBinding_cfgBindings] run-module= check-module= It would nice if these key bindings for extension modules could be put in the same file as the standard key bindings. Even nicer if the configuration dialog could be used to change all key bindings. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:48 Message: Logged In: YES user_id=819035 Using the original [IDLE Classic Mac] shortcut keys definitions, the only Command shortcuts that do anything are the following: Command-Q: tries to quit X11 instead of IDLE Command-W: closes X11 windows instead of IDLE windows Command-B: go to beginning of word Command-F: go to end of word Command-D: delete next word Command-H: hide X11 Command-M: minimize window Command-,: X11 preferences dialog ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:43 Message: Logged In: YES user_id=819035 Sorry, my confusion. Since I edited my original config-keys.def file, I forgot that the [IDLE Classic Mac] shortcuts used the Command modifier, and not Alt. This confusion is only made in my last message. If you replace "Command" with "Alt" in that message, everything makes sense: """ If I change all keybinding using the Command-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Command, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. """ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 18:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 16:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 13:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 05:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Mon Jul 14 21:39:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 13:39:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] Alt key doesn't work in IDLE for MacOSX Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Comment added) made by tiagoh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Kurt B. Kaiser (kbk) Summary: Alt key doesn't work in IDLE for MacOSX Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 20:39 Message: Logged In: YES user_id=819035 File attachment doesn't seem to be working for me using Mozilla Firebird. Here is the tentative [IDLE Modern] key binding scheme, ordered by virtual event name: [IDLE Modern] beginning-of-line= center-insert= change-indentwidth= close-all-windows= close-window= comment-region= copy= cut= dedent-region= do-nothing= end-of-file= find-again= find-in-files= find-selection= find= goto-line= history-next= history-previous= indent-region= interrupt-execution= newline-and-indent= open-class-browser= open-module= open-new-window= open-window-from-file= paste= plain-newline-and-indent= print-window= python-context-help= python-docs= redo= remove-selection= replace= restart-shell= save-copy-of-window-as-file= save-window-as-file= save-window= select-all= smart-backspace= smart-indent= tabify-region= toggle-auto-coloring= toggle-tabs= uncomment-region= undo= untabify-region= view-restart= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 20:28 Message: Logged In: YES user_id=819035 Proposal for new key binding scheme =================================== Problem ------- Due to several reasons discussed in my previous messages, the 3 available key binding schemes for IDLE in MacOSX are not satisfactory for various reasons, the main one being that the Alt/Option modifier is preempted by MacOSX for accented characters and symbols, and the Command/Apple modifier is preempted by X11 for several shortcuts. Considering that IDLE is supposed to be a tool for beginners as well as for more advanced programmers, the key binding scheme for Windows (which is currently the default scheme) also has a few problems. Although all shortcuts in the [IDLE Classic Windows] key binding scheme seem to work, they use an inconsistent mix of modifier keys that hinders learning and makes it difficult to use in platforms where modifier keys work differently. Most of these shortcuts use the Control and Alt modifiers, but some shortcuts use 2 or more modifiers or a third modifier: Control modifier: close-all-windows= Alt/Meta modifier: close-window= Shift modifier: python-context-help= Several modifiers: redo= save-copy-of-window-as-file= Proposal -------- I propose to use a new key binding scheme that uses one single modifier key for all shortcuts in order to increase learnability and portability. The Control modifier is the natural choice for the standard modifier, since unlike the Alt, Command or Windows modifiers it is not usually used for standard OS shortcuts. I am attaching to this message my ~/.idlerc/config-keys.cfg file containing the bindings for this scheme, which I have tentatively named [IDLE Modern]. My hope is to have this scheme become one of the additional schemes shipped with IDLE, and perhaps even replace the [IDLE Classic Windows] scheme as the default scheme for IDLE on all platforms. Rationale --------- I tried to preserve most bindings that have become common in Mac, Windows and Linux applications, and change non-standard bindings to standard. I have also changed all bindings that use a modifier different from Control, sometimes using a similar binding (e.g. instead of for the <> virtual event), sometimes using a completely different binding. I strived to use only alphabetical keys, numerical keys and function keys, since other characters tend to shift according to which keyboard layout one is using. For instance, in the Portuguese keyboard layout the bracket characters have to accessed using a special modifier key, labeled AltGr (for Alt Graphics) together with a numeric key (AltGr-Key-7 and AltGr-Key-8), while the slash character has to be written using Shift-Key-7. This means that the standard bindings for the <>, <> and <> virtual events are difficult if not impossible to access with a Portuguese keyboard layout. One possible solution, which I chose many years ago, is to memorize the American keyboard layout and use that layout for all programming and command-line work, regardless of the actual labels on your keys. Although not really that difficult, this is a step that most people will understandably refuse to take. A more acceptable solution is to avoid using non-alphanumeric characters, which tend to vary a lot more from one layout to the other. I also tried to bind semantically similar virtual events to neighbouring keys, as is already the case with the standard clipboard shortcuts, which occupy 3 neighbouring keys in the same row (x, c and v). For instance, all find commands are placed sequentially in the same row (f, g, h, j and k). All save commands are placed in neighbouring keys (s, e and r). The dedent and indent events are moved to the same row as 4 other events that affect a region, like comment and uncomment (numeric keys row, 1 to 9), along with some other events associated with tabs. Finally, 2 of the most used virtual events, <> and <>, are now bound to and , which should be much more obvious than and . The old bindings are hard to understand unless you have a history of Emacs ab^H^Huse, and are not as intuitive as using the arrows with a modifier key. Extension bindings ------------------ The key bindings for virtual events belonging to IDLE extensions are currently defined in config-extensions.def and are not customizable directly from IDLE. Since 4 of these virtual events currently use the Alt modifier, they conflict with the above rationale of using one single modifier key for all shortcuts, viz. the Control key. I propose to expand these currents shortcuts with another key bindings that fits in with the proposed [IDLE Modern] scheme: format-paragraph= expand-word= zoom-height= run-module= # unchanged check-module= Binding changes --------------- Comparison of [IDLE Modern] bindings to [IDLE Classic Windows] bindings: a) Identical bindings: beginning-of-line= close-all-windows= # modifier-q is a standard binding for 'quit' in Mac (increasingly used in Windows) copy= # modifier-c is a standard binding 'copy' in Windows and Mac cut= # modifier-x is a standard binding 'cut' in Windows and Mac do-nothing= end-of-file= find= # modifier-f is a standard binding for 'find' in Windows and Mac newline-and-indent= open-new-window= # modifier-n is a standard binding for 'new' in Windows and Mac open-window-from-file= # modifier-o is a standard binding for 'open' in Windows and Mac paste= # modifier-v is a standard binding for 'paste' in Windows and Mac print-window= # modifier-p is a standard binding for 'print' in Windows and Mac python-docs= remove-selection= replace= # modifier-h is a standard binding for 'replace' in Windows and Mac save-window= # modifier-s is a standard binding for 'save' in Windows and Mac select-all= # modifier-a is a standard binding for 'select-all' in Windows and Mac smart-backspace= smart-indent= undo= # modifier-z is a standard binding for 'undo' in Windows and Mac view-restart= b) Similar bindings (Alt or Meta modifier replaced with Control modifier): comment-region= open-module= uncomment-region= tabify-region= untabify-region= c) Changed bindings: center-insert= change-indentwidth= close-window= # modifier-w is a standard binding for 'close-window' in Mac (increasingly used in Windows) dedent-region= find-again= # modifier-g is a standard binding for 'find-again' in Windows and Mac find-in-files= find-selection= goto-line= # modifier-l is a common but not standard binding for 'goto-line' in Windows and Mac history-next= history-previous= indent-region= interrupt-execution= open-class-browser= plain-newline-and-indent= python-context-help= redo= # modifier-y is a common but not standard binding for 'redo' in Windows and Mac restart-shell= save-copy-of-window-as-file= save-window-as-file= toggle-auto-coloring= toggle-tabs= Bindings ordered by key ----------------------- smart-backspace= remove-selection= beginning-of-line= newline-and-indent= smart-indent= python-docs= view-restart= restart-shell= python-context-help= do-nothing= history-previous= history-next= dedent-region= indent-region= comment-region= uncomment-region= tabify-region= untabify-region= change-indentwidth= toggle-tabs= toggle-auto-coloring= select-all= open-class-browser= copy= end-of-file= save-window-as-file= find= find-again= replace= interrupt-execution= find-selection= find-in-files= goto-line= open-module= open-new-window= open-window-from-file= print-window= close-all-windows= save-copy-of-window-as-file= save-window= center-insert= plain-newline-and-indent= paste= close-window= cut= redo= undo= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-12 19:10 Message: Logged In: YES user_id=819035 Thanks for the instructive comments. Here are some answers: 1) The problems are the following: a) The standard key bindings are the IDLE Classic Windows key bindings, which do not work. - None of the many bindings that use the Alt modifier work, since the Alt (a.k.a. Option) key is used in MacOSX for accents and symbols. b) The IDLE Classic Mac key bindings do not work. - Most of them require the Command key, which for some unknown reason do not seem to work. c) The IDLE Classic Unix key bindings mostly work, but are unsatisfactory. - These bindings replace many "chord" key bindings with emacs style shortcuts, which are frankly unpleasant to use for 99% of people not used to emacs. Also, there are still several of these Unix key bindings that use the Alt modifier, and which thus do not work in MacOSX. In spite of all this, it is the most usable of the 3 default schemes. d) 5 key bindings used by extensions are currently not rebindable: Alt-Key-q, Alt-Key-slash, Alt-Key-2, Alt-Key-x and Key-F5. Since 4 of them use the Alt modifier, they do not work under MacOSX e) Some bits of extend.txt and help.txt are outdated. 2) A slightly awkward workaround to problem 1.b: What I meant was that by replacing Command with Meta in key bindings means that many but far from all Command bindings work. By chance, I discovered that using the Control-Command combination instead of just the Command modifier makes most if not all Meta bindings work. It seems as if Meta really is interpreted as Control-Command, with Command working sometimes. This is not very satisfactory, but it's better than any of the other 3 default bindings. 3) Regarding capitalization: I discovered by accident that Tk keybindings are case sensitive. However, all bindings mentioned by me treat capitals and lowercase letters identically, i.e. when I wrote Command-B, I really meant Command-b, and not Command-Shift-b. I'll take care not make that confusion from now on. 4) Command-b and Control-b: The bindings mentioned in my 2003-07-11 18:48 message are Command bindings. Command-b and Command-f really do move to the beginning and end of words, unlike Control-b and Control-f, which move one character back and one character forward. I have no idea why some these Command bindings work, but the fact is they do. 5) It might be useful to get other MacOSX users to check my findings, since there might quirks with my configuration which I'm not aware of. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 20:43 Message: Logged In: YES user_id=149084 Thank you for reporting the issues with help.txt and extend.txt. I will update these files. You are correct about the renaming, extend.txt has not been updated since the new config system was implemented. I agree it would be nice to set the extension configuration from the configuration dialog. However, we are much too close to release to contemplate doing that for 2.3. The extension feature is intended to incorporate 3rd party features so the enhancement of the config dialog would have to be suitably general. Your problem appears to be down to one thing: none of IDLE's "Classic Mac" Command combinations in your config-keys.def work. If I understand you correctly, you are saying that e.g. replacing "Command-Key-w" by "Meta-Key-w" in config-keys.def causes the <> event to work correctly? Note that Tk is very picky about capitalization. "Command-Key-w" is not the same as "Command-Key-W". Please be sure that your file is correct in this regard. If you can get everything working by doing this, would you please upload the modified version of your config-keys.def and let me know what the remaining problems are, if any. In your messages you have variously said that both "Command-B" and "Ctl-b" keystrokes go to the beginning of a word. Is this correct? And do you really mean "Apple/Shift/b" in the first case? The Ctl-b binding and others like it that you have mentioned in your earlier message are part of a number of default Tk bindings that have not been disabled in IDLE. http://www.tcl.tk/man/tcl8.3/TkCmd/text.htm#M141 Clearly, there may not be complete compatibility with this documentation in the Tk Mac implementation. But that is the origin of the bindings. By the way, the way to customize is not to modify config-keys.def, but to modify your .idlerc/config-keys.cfg or any of the other files in that directory. That is what the config dialog does, and it is quite all right to modify it manually as long as you carefully follow the format. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 19:08 Message: Logged In: YES user_id=819035 The file extend.txt references two files that do not exist: keydefs and config.txt I suppose the former corresponds config-keys.def, while the latter has been split into 3 files: config-main.def, config-extensions.def and config-highlight.def. Is this correct? Looking into config-extensions.def, I can finally see were those non-standard key sequences are defined: [FormatParagraph_cfgBindings] format-paragraph= (...) [AutoExpand_cfgBindings] expand-word= (...) [ZoomHeight_cfgBindings] zoom-height= (...) [ScriptBinding_cfgBindings] run-module= check-module= It would nice if these key bindings for extension modules could be put in the same file as the standard key bindings. Even nicer if the configuration dialog could be used to change all key bindings. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:48 Message: Logged In: YES user_id=819035 Using the original [IDLE Classic Mac] shortcut keys definitions, the only Command shortcuts that do anything are the following: Command-Q: tries to quit X11 instead of IDLE Command-W: closes X11 windows instead of IDLE windows Command-B: go to beginning of word Command-F: go to end of word Command-D: delete next word Command-H: hide X11 Command-M: minimize window Command-,: X11 preferences dialog ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:43 Message: Logged In: YES user_id=819035 Sorry, my confusion. Since I edited my original config-keys.def file, I forgot that the [IDLE Classic Mac] shortcuts used the Command modifier, and not Alt. This confusion is only made in my last message. If you replace "Command" with "Alt" in that message, everything makes sense: """ If I change all keybinding using the Command-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Command, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. """ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 18:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 16:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 13:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 05:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Mon Jul 14 22:47:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 14:47:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-722763 ] weakref: proxy_print and proxy_repr incons. Message-ID: Bugs item #722763, was opened at 2003-04-16 17:49 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=722763&group_id=5470 Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Guido van Rossum (gvanrossum) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: weakref: proxy_print and proxy_repr incons. Initial Comment: For weakref.proxy, the behavior of proxy_print() in "cooked" mode is inconsistent with the behavior of proxy_repr(). "cooked" mode printing is used when a value is displayed at the command line. Sample session: >>> class C: pass ... >>> from weakref import proxy >>> a = C() >>> p = proxy(a) >>> p <__main__.C instance at 0x400e864c> >>> print repr(p) >>> The output should be the same in both cases. (My suggestion: get rid of proxy_print. Might be a tad slower in extreme cases, but gets this right with ease. :-) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-14 17:46 Message: Logged In: YES user_id=3066 Fixed in the manner suggested in Objects/weakrefobject.c revision 1.13. Backport candidate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=722763&group_id=5470 From noreply@sourceforge.net Tue Jul 15 01:42:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 17:42:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-771097 ] frozen programs fail due to implicit import of "warnings" Message-ID: Bugs item #771097, was opened at 2003-07-15 03:32 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771097&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: frozen programs fail due to implicit import of "warnings" Initial Comment: With Python 2.3b2, pythonrun.c now imports the "warnings" module at startup, which causes problems with freezing programs like py2exe, cx_Freeze and Installer The main reason there is a problem is because this takes place during Py_Initialize() so there is no way of overriding the import so that it can find a copy of the warnings module in anything but the filesystem. Is there any way of getting around this? What's worse is that warnings.py imports a raft of other modules (14 others which I can list if necesary) and so the workaround of simply copying the needed files is unwieldy. This is somewhat related to bug 683658. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-07-15 10:42 Message: Logged In: YES user_id=14198 I'm attaching a patch that goes some way to solving this. Note that all this is really a hack for bug 683658. The new patch does the following: * Still attempt to get the warnings module at startup, but into a static variable. Clear the Python error if we fail. * New function, PyModule_GetWarningsModule() - this attempts to use the module loaded at init time. If this fails, it attempts to look up the module in sys.__modules__. If this fails, it gives up (as it still can't do anything to acquire the import lock) * External functions (eg PyErr_Warn) use this function. The end result of this is that even if the import for warnings fails at startup, the C code can still use the warning module, *iff* the warnings module has previously been imported. Freeze etc could then take the approach of bootstrapping their import mechanism (which they must do now), then manually importing the warnings module. Not ideal, but better than what exists now :) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-15 04:02 Message: Logged In: YES user_id=619560 In current CVS (revision 2.193 of dist/src/Python/pythonrun.c) at line 193 there is this line PyModule_WarningsModule = PyImport_ImportModule("warnings"); There is no check afterward for any errors. Couldn't a PyErr_Clear() be done so that further statements don't fail because the import of warnings failed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771097&group_id=5470 From noreply@sourceforge.net Tue Jul 15 02:36:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 18:36:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] IDLE/MAC: Command / Alt Bindings Don't Work Message-ID: Bugs item #768469, was opened at 2003-07-09 08:49 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Kurt B. Kaiser (kbk) >Summary: IDLE/MAC: Command / Alt Bindings Don't Work Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-14 20:36 Message: Logged In: YES user_id=149084 I'd like to focus on the bug rather than an RFE for a new keyset. I'd suggest that you use [IDLE Modern] for a couple of months and then post your suggestion to the Idle-dev email list for comment. Please note that the Shift modifier isn't working because there is a bug (already reported on the IDLEfork Tracker). I have asked the IDLEfork Mac expert to take a look at this bug, which is that the Command-[something] bindings don't work (unless they happen to be default Tk bindings). There is also an issue with the use of Alt keys in the extensions. Originally, IDLE had the ability to define extension keybindings for each platform. These were eliminated in IDLEfork with, I believe, the intention to expand the configuration dialog to replace them. However, that has not as yet been accomplished. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 15:39 Message: Logged In: YES user_id=819035 File attachment doesn't seem to be working for me using Mozilla Firebird. Here is the tentative [IDLE Modern] key binding scheme, ordered by virtual event name: [IDLE Modern] beginning-of-line= center-insert= change-indentwidth= close-all-windows= close-window= comment-region= copy= cut= dedent-region= do-nothing= end-of-file= find-again= find-in-files= find-selection= find= goto-line= history-next= history-previous= indent-region= interrupt-execution= newline-and-indent= open-class-browser= open-module= open-new-window= open-window-from-file= paste= plain-newline-and-indent= print-window= python-context-help= python-docs= redo= remove-selection= replace= restart-shell= save-copy-of-window-as-file= save-window-as-file= save-window= select-all= smart-backspace= smart-indent= tabify-region= toggle-auto-coloring= toggle-tabs= uncomment-region= undo= untabify-region= view-restart= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 15:28 Message: Logged In: YES user_id=819035 Proposal for new key binding scheme =================================== Problem ------- Due to several reasons discussed in my previous messages, the 3 available key binding schemes for IDLE in MacOSX are not satisfactory for various reasons, the main one being that the Alt/Option modifier is preempted by MacOSX for accented characters and symbols, and the Command/Apple modifier is preempted by X11 for several shortcuts. Considering that IDLE is supposed to be a tool for beginners as well as for more advanced programmers, the key binding scheme for Windows (which is currently the default scheme) also has a few problems. Although all shortcuts in the [IDLE Classic Windows] key binding scheme seem to work, they use an inconsistent mix of modifier keys that hinders learning and makes it difficult to use in platforms where modifier keys work differently. Most of these shortcuts use the Control and Alt modifiers, but some shortcuts use 2 or more modifiers or a third modifier: Control modifier: close-all-windows= Alt/Meta modifier: close-window= Shift modifier: python-context-help= Several modifiers: redo= save-copy-of-window-as-file= Proposal -------- I propose to use a new key binding scheme that uses one single modifier key for all shortcuts in order to increase learnability and portability. The Control modifier is the natural choice for the standard modifier, since unlike the Alt, Command or Windows modifiers it is not usually used for standard OS shortcuts. I am attaching to this message my ~/.idlerc/config-keys.cfg file containing the bindings for this scheme, which I have tentatively named [IDLE Modern]. My hope is to have this scheme become one of the additional schemes shipped with IDLE, and perhaps even replace the [IDLE Classic Windows] scheme as the default scheme for IDLE on all platforms. Rationale --------- I tried to preserve most bindings that have become common in Mac, Windows and Linux applications, and change non-standard bindings to standard. I have also changed all bindings that use a modifier different from Control, sometimes using a similar binding (e.g. instead of for the <> virtual event), sometimes using a completely different binding. I strived to use only alphabetical keys, numerical keys and function keys, since other characters tend to shift according to which keyboard layout one is using. For instance, in the Portuguese keyboard layout the bracket characters have to accessed using a special modifier key, labeled AltGr (for Alt Graphics) together with a numeric key (AltGr-Key-7 and AltGr-Key-8), while the slash character has to be written using Shift-Key-7. This means that the standard bindings for the <>, <> and <> virtual events are difficult if not impossible to access with a Portuguese keyboard layout. One possible solution, which I chose many years ago, is to memorize the American keyboard layout and use that layout for all programming and command-line work, regardless of the actual labels on your keys. Although not really that difficult, this is a step that most people will understandably refuse to take. A more acceptable solution is to avoid using non-alphanumeric characters, which tend to vary a lot more from one layout to the other. I also tried to bind semantically similar virtual events to neighbouring keys, as is already the case with the standard clipboard shortcuts, which occupy 3 neighbouring keys in the same row (x, c and v). For instance, all find commands are placed sequentially in the same row (f, g, h, j and k). All save commands are placed in neighbouring keys (s, e and r). The dedent and indent events are moved to the same row as 4 other events that affect a region, like comment and uncomment (numeric keys row, 1 to 9), along with some other events associated with tabs. Finally, 2 of the most used virtual events, <> and <>, are now bound to and , which should be much more obvious than and . The old bindings are hard to understand unless you have a history of Emacs ab^H^Huse, and are not as intuitive as using the arrows with a modifier key. Extension bindings ------------------ The key bindings for virtual events belonging to IDLE extensions are currently defined in config-extensions.def and are not customizable directly from IDLE. Since 4 of these virtual events currently use the Alt modifier, they conflict with the above rationale of using one single modifier key for all shortcuts, viz. the Control key. I propose to expand these currents shortcuts with another key bindings that fits in with the proposed [IDLE Modern] scheme: format-paragraph= expand-word= zoom-height= run-module= # unchanged check-module= Binding changes --------------- Comparison of [IDLE Modern] bindings to [IDLE Classic Windows] bindings: a) Identical bindings: beginning-of-line= close-all-windows= # modifier-q is a standard binding for 'quit' in Mac (increasingly used in Windows) copy= # modifier-c is a standard binding 'copy' in Windows and Mac cut= # modifier-x is a standard binding 'cut' in Windows and Mac do-nothing= end-of-file= find= # modifier-f is a standard binding for 'find' in Windows and Mac newline-and-indent= open-new-window= # modifier-n is a standard binding for 'new' in Windows and Mac open-window-from-file= # modifier-o is a standard binding for 'open' in Windows and Mac paste= # modifier-v is a standard binding for 'paste' in Windows and Mac print-window= # modifier-p is a standard binding for 'print' in Windows and Mac python-docs= remove-selection= replace= # modifier-h is a standard binding for 'replace' in Windows and Mac save-window= # modifier-s is a standard binding for 'save' in Windows and Mac select-all= # modifier-a is a standard binding for 'select-all' in Windows and Mac smart-backspace= smart-indent= undo= # modifier-z is a standard binding for 'undo' in Windows and Mac view-restart= b) Similar bindings (Alt or Meta modifier replaced with Control modifier): comment-region= open-module= uncomment-region= tabify-region= untabify-region= c) Changed bindings: center-insert= change-indentwidth= close-window= # modifier-w is a standard binding for 'close-window' in Mac (increasingly used in Windows) dedent-region= find-again= # modifier-g is a standard binding for 'find-again' in Windows and Mac find-in-files= find-selection= goto-line= # modifier-l is a common but not standard binding for 'goto-line' in Windows and Mac history-next= history-previous= indent-region= interrupt-execution= open-class-browser= plain-newline-and-indent= python-context-help= redo= # modifier-y is a common but not standard binding for 'redo' in Windows and Mac restart-shell= save-copy-of-window-as-file= save-window-as-file= toggle-auto-coloring= toggle-tabs= Bindings ordered by key ----------------------- smart-backspace= remove-selection= beginning-of-line= newline-and-indent= smart-indent= python-docs= view-restart= restart-shell= python-context-help= do-nothing= history-previous= history-next= dedent-region= indent-region= comment-region= uncomment-region= tabify-region= untabify-region= change-indentwidth= toggle-tabs= toggle-auto-coloring= select-all= open-class-browser= copy= end-of-file= save-window-as-file= find= find-again= replace= interrupt-execution= find-selection= find-in-files= goto-line= open-module= open-new-window= open-window-from-file= print-window= close-all-windows= save-copy-of-window-as-file= save-window= center-insert= plain-newline-and-indent= paste= close-window= cut= redo= undo= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-12 14:10 Message: Logged In: YES user_id=819035 Thanks for the instructive comments. Here are some answers: 1) The problems are the following: a) The standard key bindings are the IDLE Classic Windows key bindings, which do not work. - None of the many bindings that use the Alt modifier work, since the Alt (a.k.a. Option) key is used in MacOSX for accents and symbols. b) The IDLE Classic Mac key bindings do not work. - Most of them require the Command key, which for some unknown reason do not seem to work. c) The IDLE Classic Unix key bindings mostly work, but are unsatisfactory. - These bindings replace many "chord" key bindings with emacs style shortcuts, which are frankly unpleasant to use for 99% of people not used to emacs. Also, there are still several of these Unix key bindings that use the Alt modifier, and which thus do not work in MacOSX. In spite of all this, it is the most usable of the 3 default schemes. d) 5 key bindings used by extensions are currently not rebindable: Alt-Key-q, Alt-Key-slash, Alt-Key-2, Alt-Key-x and Key-F5. Since 4 of them use the Alt modifier, they do not work under MacOSX e) Some bits of extend.txt and help.txt are outdated. 2) A slightly awkward workaround to problem 1.b: What I meant was that by replacing Command with Meta in key bindings means that many but far from all Command bindings work. By chance, I discovered that using the Control-Command combination instead of just the Command modifier makes most if not all Meta bindings work. It seems as if Meta really is interpreted as Control-Command, with Command working sometimes. This is not very satisfactory, but it's better than any of the other 3 default bindings. 3) Regarding capitalization: I discovered by accident that Tk keybindings are case sensitive. However, all bindings mentioned by me treat capitals and lowercase letters identically, i.e. when I wrote Command-B, I really meant Command-b, and not Command-Shift-b. I'll take care not make that confusion from now on. 4) Command-b and Control-b: The bindings mentioned in my 2003-07-11 18:48 message are Command bindings. Command-b and Command-f really do move to the beginning and end of words, unlike Control-b and Control-f, which move one character back and one character forward. I have no idea why some these Command bindings work, but the fact is they do. 5) It might be useful to get other MacOSX users to check my findings, since there might quirks with my configuration which I'm not aware of. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 15:43 Message: Logged In: YES user_id=149084 Thank you for reporting the issues with help.txt and extend.txt. I will update these files. You are correct about the renaming, extend.txt has not been updated since the new config system was implemented. I agree it would be nice to set the extension configuration from the configuration dialog. However, we are much too close to release to contemplate doing that for 2.3. The extension feature is intended to incorporate 3rd party features so the enhancement of the config dialog would have to be suitably general. Your problem appears to be down to one thing: none of IDLE's "Classic Mac" Command combinations in your config-keys.def work. If I understand you correctly, you are saying that e.g. replacing "Command-Key-w" by "Meta-Key-w" in config-keys.def causes the <> event to work correctly? Note that Tk is very picky about capitalization. "Command-Key-w" is not the same as "Command-Key-W". Please be sure that your file is correct in this regard. If you can get everything working by doing this, would you please upload the modified version of your config-keys.def and let me know what the remaining problems are, if any. In your messages you have variously said that both "Command-B" and "Ctl-b" keystrokes go to the beginning of a word. Is this correct? And do you really mean "Apple/Shift/b" in the first case? The Ctl-b binding and others like it that you have mentioned in your earlier message are part of a number of default Tk bindings that have not been disabled in IDLE. http://www.tcl.tk/man/tcl8.3/TkCmd/text.htm#M141 Clearly, there may not be complete compatibility with this documentation in the Tk Mac implementation. But that is the origin of the bindings. By the way, the way to customize is not to modify config-keys.def, but to modify your .idlerc/config-keys.cfg or any of the other files in that directory. That is what the config dialog does, and it is quite all right to modify it manually as long as you carefully follow the format. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 14:08 Message: Logged In: YES user_id=819035 The file extend.txt references two files that do not exist: keydefs and config.txt I suppose the former corresponds config-keys.def, while the latter has been split into 3 files: config-main.def, config-extensions.def and config-highlight.def. Is this correct? Looking into config-extensions.def, I can finally see were those non-standard key sequences are defined: [FormatParagraph_cfgBindings] format-paragraph= (...) [AutoExpand_cfgBindings] expand-word= (...) [ZoomHeight_cfgBindings] zoom-height= (...) [ScriptBinding_cfgBindings] run-module= check-module= It would nice if these key bindings for extension modules could be put in the same file as the standard key bindings. Even nicer if the configuration dialog could be used to change all key bindings. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 13:48 Message: Logged In: YES user_id=819035 Using the original [IDLE Classic Mac] shortcut keys definitions, the only Command shortcuts that do anything are the following: Command-Q: tries to quit X11 instead of IDLE Command-W: closes X11 windows instead of IDLE windows Command-B: go to beginning of word Command-F: go to end of word Command-D: delete next word Command-H: hide X11 Command-M: minimize window Command-,: X11 preferences dialog ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 13:43 Message: Logged In: YES user_id=819035 Sorry, my confusion. Since I edited my original config-keys.def file, I forgot that the [IDLE Classic Mac] shortcuts used the Command modifier, and not Alt. This confusion is only made in my last message. If you replace "Command" with "Alt" in that message, everything makes sense: """ If I change all keybinding using the Command-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Command, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. """ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 13:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 11:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 11:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 14:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 14:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 11:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 08:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 00:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Tue Jul 15 02:58:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 18:58:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-771334 ] pydoc.TextDoc raises for some kinds of objects Message-ID: Bugs item #771334, was opened at 2003-07-14 21:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771334&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc.TextDoc raises for some kinds of objects Initial Comment: TextDoc.spill calls inherited Doc.document(getattr(object, name), name, mod, object) Doc.document builds args=(getattr(object, name), name, mod, object) Doc.document calls TextDoc.docother(self, *args) args[3] maps to maxlen=None in TextDoc.docother.. which expects it to be an integer (I think 70 in the other spill functions), but it's really just an arbitrary object.. so an exception gets thrown. TextDoc.spill (line 1064) should be changed to call self.document(getattr(object, name), name, mod) instead, as the object is not appropriate to be used as maxlen. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771334&group_id=5470 From noreply@sourceforge.net Tue Jul 15 06:49:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 22:49:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-771408 ] bzip2 and zlib need update: security flaws Message-ID: Bugs item #771408, was opened at 2003-07-15 05: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=771408&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: bzip2 and zlib need update: security flaws Initial Comment: I note that both zlib and bzip2 have newer versions purporting to fix security problems (buffer overrun possibilities). They each suggest upgrading if you are using the libraries. I'm not certain how the packaging goes, but I suspect the Windows install includes these packages while the other reference them. Unfortunately, I am out of my depth in determining where to look and/or update. I thought I'd just point out this announcement, and hope someone who knows the vagaries of packagin is listening. The latest version that are being looked for (and the home page for the package): http://www.gzip.org/zlib/ 1.1.4 http://sources.redhat.com/bzip2/ 1.0.2 -Scott David Daniels ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771408&group_id=5470 From noreply@sourceforge.net Tue Jul 15 07:57:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 14 Jul 2003 23:57:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-771429 ] Signals discard one level of exception handling Message-ID: Bugs item #771429, was opened at 2003-07-15 06: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=771429&group_id=5470 Category: Python Interpreter Core Group: Python 2.1.2 Status: Open Resolution: None Priority: 5 Submitted By: Dieter Maurer (dmaurer) Assigned to: Nobody/Anonymous (nobody) Summary: Signals discard one level of exception handling Initial Comment: Signals handled by Python (especially KeyboardInterrupt) may discard one level of exception handling. Consider the following code fragment: try: # outer exception handling level try: # inner exception handling level blocking_external_extension_function() except: print "inner exception handling" except: print "outer exception handling" Assume that "blocking_external_extension_function" is an external function (implemented in "C") that blocks until interrupted by a signal (EINTR) and then returns with an exception but without handling the signal. In our concrete case, "blocking_external_extension_function" has been "psycopg.connect" (the database "connect" from the Python-PostgreSQL bridge "psycopg"). In this case, when you interrupt the execution, while "blocking_external_extension_function" waits, the "KeyboardInterrupt" is not caught in the inner "try: ...except: ..." but only in the outer "try: ... except: ..." The following happens in detail in Python's main interpreter loop: * "blocking_external_extension_function" returns with an exception. * Python sets the next instruction to the exception handler of the inner exception handling * Python begins a new run through its main loop. At the start, it detects the "KeyboardInterrupt" signal. It now thinks, the "KeyboardInterrupt" were caused inside the inner exception handler and pops this exception handling level without executing it. The interpreter has lost one level of exception handling. The behaviour would probably better fit with expectations, when the interpreter would check for signals at the end of its main loop and before it sets its instruction pointer to the exception handler. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771429&group_id=5470 From noreply@sourceforge.net Tue Jul 15 10:23:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 02:23:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-771479 ] pyconfig.h duplicates common defines Message-ID: Bugs item #771479, was opened at 2003-07-15 09: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=771479&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel Uitdehaag (michielu) Assigned to: Nobody/Anonymous (nobody) Summary: pyconfig.h duplicates common defines Initial Comment: When combining the Python library with other packages, or with your own 'configure'-d package, warnings like: /home/michielu/pybuild/config.h:402: warning: `PACKAGE_VERSION' redefined /usr/include/python2.3/pyconfig.h:663: warning: this is the location of the previous definition The same goes for stuff like PACKAGE_STRING, PACKAGE_TARNAME and PACKAGE_NAME. It is likely that more defines like HAVE_FORK, etc, can be duplicated. Such configuration values should not be installed 'as-is' from the ./configure output. Instead, it is suggested the installation preprocesses a header configuration file and uses and installs that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771479&group_id=5470 From noreply@sourceforge.net Tue Jul 15 15:09:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 07:09:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-771408 ] bzip2 and zlib need update: security flaws Message-ID: Bugs item #771408, was opened at 2003-07-15 01: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=771408&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Scott David Daniels (scott_daniels) Assigned to: Nobody/Anonymous (nobody) Summary: bzip2 and zlib need update: security flaws Initial Comment: I note that both zlib and bzip2 have newer versions purporting to fix security problems (buffer overrun possibilities). They each suggest upgrading if you are using the libraries. I'm not certain how the packaging goes, but I suspect the Windows install includes these packages while the other reference them. Unfortunately, I am out of my depth in determining where to look and/or update. I thought I'd just point out this announcement, and hope someone who knows the vagaries of packagin is listening. The latest version that are being looked for (and the home page for the package): http://www.gzip.org/zlib/ 1.1.4 http://sources.redhat.com/bzip2/ 1.0.2 -Scott David Daniels ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-15 10:09 Message: Logged In: YES user_id=31435 Python 2.3a1 already used zlib 1.1.4 last year -- see the Python NEWS file. Don't know about bz2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771408&group_id=5470 From noreply@sourceforge.net Tue Jul 15 15:16:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 07:16:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-771408 ] bzip2 and zlib need update: security flaws Message-ID: Bugs item #771408, was opened at 2003-07-15 01: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=771408&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Scott David Daniels (scott_daniels) >Assigned to: Tim Peters (tim_one) Summary: bzip2 and zlib need update: security flaws Initial Comment: I note that both zlib and bzip2 have newer versions purporting to fix security problems (buffer overrun possibilities). They each suggest upgrading if you are using the libraries. I'm not certain how the packaging goes, but I suspect the Windows install includes these packages while the other reference them. Unfortunately, I am out of my depth in determining where to look and/or update. I thought I'd just point out this announcement, and hope someone who knows the vagaries of packagin is listening. The latest version that are being looked for (and the home page for the package): http://www.gzip.org/zlib/ 1.1.4 http://sources.redhat.com/bzip2/ 1.0.2 -Scott David Daniels ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-15 10:16 Message: Logged In: YES user_id=31435 And we've built from bzip2-1.0.2.tar.gz on Windows from the start. So closing this, as it appears there's nothing to do. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-15 10:09 Message: Logged In: YES user_id=31435 Python 2.3a1 already used zlib 1.1.4 last year -- see the Python NEWS file. Don't know about bz2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771408&group_id=5470 From noreply@sourceforge.net Tue Jul 15 19:54:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 11:54:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-771479 ] pyconfig.h duplicates common defines Message-ID: Bugs item #771479, was opened at 2003-07-15 05:23 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771479&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel Uitdehaag (michielu) Assigned to: Nobody/Anonymous (nobody) Summary: pyconfig.h duplicates common defines Initial Comment: When combining the Python library with other packages, or with your own 'configure'-d package, warnings like: /home/michielu/pybuild/config.h:402: warning: `PACKAGE_VERSION' redefined /usr/include/python2.3/pyconfig.h:663: warning: this is the location of the previous definition The same goes for stuff like PACKAGE_STRING, PACKAGE_TARNAME and PACKAGE_NAME. It is likely that more defines like HAVE_FORK, etc, can be duplicated. Such configuration values should not be installed 'as-is' from the ./configure output. Instead, it is suggested the installation preprocesses a header configuration file and uses and installs that. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-15 14:54 Message: Logged In: YES user_id=33168 Michiel can you try the version in CVS? I believe many of the PACKAGE_* macros have been removed. I don't know if this is a problem any longer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771479&group_id=5470 From noreply@sourceforge.net Tue Jul 15 20:13:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 12:13:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-763928 ] test_bsddb3 crashes if run after test_locale Message-ID: Bugs item #763928, was opened at 2003-07-01 16:25 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763928&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Neil Schemenauer (nascheme) Assigned to: Martin v. Löwis (loewis) Summary: test_bsddb3 crashes if run after test_locale Initial Comment: I found this while testing for the 2.3b2 release. This crashes on both W2K and Linux: ./python Lib/test/regrtest.py -u bsddb test_logging test_bsddb3 Only the 'locale.setlocale(locale.LC_ALL, '')' line of test_logging is necessary to trigger the bug. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-15 21:13 Message: Logged In: YES user_id=21627 This is fixed in _bsddb.c 1.17. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763928&group_id=5470 From noreply@sourceforge.net Tue Jul 15 20:15:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 12:15:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-630494 ] expat causes a core dump Message-ID: Bugs item #630494, was opened at 2002-10-29 15:37 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630494&group_id=5470 Category: XML Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Martin v. Löwis (loewis) Summary: expat causes a core dump Initial Comment: Raising an exception inside a StartNamespaceDeclHandler causes python to dump core. The attached program will cause a segmentation fault. Note it is possible to raise exception in the StartElementHandler and EndElementHandler with Python 2.0 >python2.0 expat_testje.py None 123 Segmentation fault (core dumped) with Python 2.2.1 >python2 expat_testje.py None 123 Segmentation fault (core dumped) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-15 21:15 Message: Logged In: YES user_id=21627 I can't reproduce the crashes for 2.3, as of today. Can anybody else confirm that the problem has gone away for 2.3? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-26 11:45 Message: Logged In: YES user_id=21627 It appears to be fixed in 2.3, although I haven't investigated which particular change has fixed it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-29 23:14 Message: Logged In: YES user_id=33168 This core dumps on 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630494&group_id=5470 From noreply@sourceforge.net Tue Jul 15 21:08:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 13:08:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-630494 ] expat causes a core dump Message-ID: Bugs item #630494, was opened at 2002-10-29 09:37 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630494&group_id=5470 Category: XML Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Martin v. Löwis (loewis) Summary: expat causes a core dump Initial Comment: Raising an exception inside a StartNamespaceDeclHandler causes python to dump core. The attached program will cause a segmentation fault. Note it is possible to raise exception in the StartElementHandler and EndElementHandler with Python 2.0 >python2.0 expat_testje.py None 123 Segmentation fault (core dumped) with Python 2.2.1 >python2 expat_testje.py None 123 Segmentation fault (core dumped) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-15 16:08 Message: Logged In: YES user_id=31435 FYI, on Win2K the test program dies w/ a segfault under 2.2.3 and under 2.3 CVS displays None 123 Traceback (most recent call last): File "\code\expat_testje.py", line 19, in ? parser.Parse("""een twee drie""", 1) File "\code\expat_testje.py", line 7, in handle_start_namespace raise Exception("Something is wrong here!") Exception: Something is wrong here! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-15 15:15 Message: Logged In: YES user_id=21627 I can't reproduce the crashes for 2.3, as of today. Can anybody else confirm that the problem has gone away for 2.3? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-26 05:45 Message: Logged In: YES user_id=21627 It appears to be fixed in 2.3, although I haven't investigated which particular change has fixed it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-29 17:14 Message: Logged In: YES user_id=33168 This core dumps on 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630494&group_id=5470 From noreply@sourceforge.net Tue Jul 15 21:25:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 13:25:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-630494 ] expat causes a core dump Message-ID: Bugs item #630494, was opened at 2002-10-29 09:37 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630494&group_id=5470 Category: XML >Group: 3rd Party >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: MM Zeeman (mmzeeman) Assigned to: Martin v. Löwis (loewis) Summary: expat causes a core dump Initial Comment: Raising an exception inside a StartNamespaceDeclHandler causes python to dump core. The attached program will cause a segmentation fault. Note it is possible to raise exception in the StartElementHandler and EndElementHandler with Python 2.0 >python2.0 expat_testje.py None 123 Segmentation fault (core dumped) with Python 2.2.1 >python2 expat_testje.py None 123 Segmentation fault (core dumped) ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-15 16:25 Message: Logged In: YES user_id=3066 I suspect this has to do with a change in Expat itself. An older version of Expat contained a problem which would cause it to attempt to call a missing handler in some cases. Specifically, the exception in the namespace start handler causes the Python binding to clear the handlers, at which point Expat would attempt to call the start element handler which had been replaced with a NULL pointer. Expat wasn't being careful about changes to the parser object caused by Expat API calls; this was fixed in Expat 1.95.6. Closing this as a third-party bug. Python 2.3 includes a sufficiently modern version of Expat. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-15 16:08 Message: Logged In: YES user_id=31435 FYI, on Win2K the test program dies w/ a segfault under 2.2.3 and under 2.3 CVS displays None 123 Traceback (most recent call last): File "\code\expat_testje.py", line 19, in ? parser.Parse("""een twee drie""", 1) File "\code\expat_testje.py", line 7, in handle_start_namespace raise Exception("Something is wrong here!") Exception: Something is wrong here! ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-15 15:15 Message: Logged In: YES user_id=21627 I can't reproduce the crashes for 2.3, as of today. Can anybody else confirm that the problem has gone away for 2.3? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-01-26 05:45 Message: Logged In: YES user_id=21627 It appears to be fixed in 2.3, although I haven't investigated which particular change has fixed it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-10-29 17:14 Message: Logged In: YES user_id=33168 This core dumps on 2.2.2 and 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=630494&group_id=5470 From noreply@sourceforge.net Tue Jul 15 21:45:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 13:45:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-453683 ] In 2.2, types are callable Message-ID: Bugs item #453683, was opened at 2001-08-21 07:31 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453683&group_id=5470 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: In 2.2, types are callable Initial Comment: http://python.sourceforge.net/devel-docs/ref/types.html lists all the callable types, but it does not mention that (in 2.2) type objects themselves are callable (it only mentions classes, but it definitely seems it's only talking about "classic classes" here). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-15 16:45 Message: Logged In: YES user_id=3066 Fixed in Doc/ref/ref3.tex revision 1.109. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=453683&group_id=5470 From noreply@sourceforge.net Tue Jul 15 22:26:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 14:26:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-771479 ] pyconfig.h duplicates common defines Message-ID: Bugs item #771479, was opened at 2003-07-15 09:23 Message generated for change (Comment added) made by michielu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771479&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michiel Uitdehaag (michielu) Assigned to: Nobody/Anonymous (nobody) Summary: pyconfig.h duplicates common defines Initial Comment: When combining the Python library with other packages, or with your own 'configure'-d package, warnings like: /home/michielu/pybuild/config.h:402: warning: `PACKAGE_VERSION' redefined /usr/include/python2.3/pyconfig.h:663: warning: this is the location of the previous definition The same goes for stuff like PACKAGE_STRING, PACKAGE_TARNAME and PACKAGE_NAME. It is likely that more defines like HAVE_FORK, etc, can be duplicated. Such configuration values should not be installed 'as-is' from the ./configure output. Instead, it is suggested the installation preprocesses a header configuration file and uses and installs that. ---------------------------------------------------------------------- >Comment By: Michiel Uitdehaag (michielu) Date: 2003-07-15 21:26 Message: Logged In: YES user_id=35033 I checked the CVS version through the CVS browser. The PACKAGE_ macro's are still there, but only the pyconfig.h.in is available obviously and it features an #undef there. The configure will likely convert that to a #define. Anyway, the _real_ problem is not the PACKAGE_ macro's, which happen to be identical between the Python and the ImageMagick applications (where I submitted a similar bug report). The _real_ problem is that the defines used in pyconfig.h are very general, like HAVE_TERM or HAVE_THREAD. It is likely that a package will define those macro's itself, especially if it is a 'configure'-d package. These macro's need to be prepended with PY_ for example. Because most of these macro's are not needed for the include files (if any at all ofcourse, in which case the entire file need not be installed), I suggest that only the macro's needed for install are duplicated in a separate file, prefixed with PY_ and have the source code check for both versions of the macro. Or, alternatively, preprocess the pyconfig.h after creation and before building (the root Makefile seems a logical place) and convert it to a new pyconfig.h with the proper PY_ prefix. And use these macro's exclusively in the python code. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-15 18:54 Message: Logged In: YES user_id=33168 Michiel can you try the version in CVS? I believe many of the PACKAGE_* macros have been removed. I don't know if this is a problem any longer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771479&group_id=5470 From noreply@sourceforge.net Tue Jul 15 23:01:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 15:01:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-518989 ] Import statement Index ref. broken Message-ID: Bugs item #518989, was opened at 2002-02-18 02:16 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518989&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Wayne C. Smith (wcsmith) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Import statement Index ref. broken Initial Comment: In the Python Reference Manual 2/4/02 2.3a0 the Index entry for the Import statement points to the wrong place. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-15 18:01 Message: Logged In: YES user_id=3066 There are a number of weird linking issues with regard to the index entries in the HTML. These are due to differences in processing models between the tools used for typeset documentation and HTML generation. I *think* I've fixed a lot of these (including the one described in this report) by changing some of the processing-order control in Doc/perl/python.perl revision 1.136. I've also cleaned up some other indexing of import-related documentation in Doc/ref/ref6.tex revision 1.67. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518989&group_id=5470 From noreply@sourceforge.net Tue Jul 15 23:37:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 15:37:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 9 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX, 2.3b1, socketmodule.c compilation errors Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15: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 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply@sourceforge.net Wed Jul 16 00:04:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 16:04:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-771097 ] frozen programs fail due to implicit import of "warnings" Message-ID: Bugs item #771097, was opened at 2003-07-15 03:32 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771097&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Anthony Tuininga (atuining) >Assigned to: Mark Hammond (mhammond) Summary: frozen programs fail due to implicit import of "warnings" Initial Comment: With Python 2.3b2, pythonrun.c now imports the "warnings" module at startup, which causes problems with freezing programs like py2exe, cx_Freeze and Installer The main reason there is a problem is because this takes place during Py_Initialize() so there is no way of overriding the import so that it can find a copy of the warnings module in anything but the filesystem. Is there any way of getting around this? What's worse is that warnings.py imports a raft of other modules (14 others which I can list if necesary) and so the workaround of simply copying the needed files is unwieldy. This is somewhat related to bug 683658. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-07-16 09:04 Message: Logged In: YES user_id=14198 Checking in pythonrun.c; new revision: 2.194; previous revision: 2.193 Checking in errors.c; new revision: 2.78; previous revision: 2.77 ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-15 10:42 Message: Logged In: YES user_id=14198 I'm attaching a patch that goes some way to solving this. Note that all this is really a hack for bug 683658. The new patch does the following: * Still attempt to get the warnings module at startup, but into a static variable. Clear the Python error if we fail. * New function, PyModule_GetWarningsModule() - this attempts to use the module loaded at init time. If this fails, it attempts to look up the module in sys.__modules__. If this fails, it gives up (as it still can't do anything to acquire the import lock) * External functions (eg PyErr_Warn) use this function. The end result of this is that even if the import for warnings fails at startup, the C code can still use the warning module, *iff* the warnings module has previously been imported. Freeze etc could then take the approach of bootstrapping their import mechanism (which they must do now), then manually importing the warnings module. Not ideal, but better than what exists now :) ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-15 04:02 Message: Logged In: YES user_id=619560 In current CVS (revision 2.193 of dist/src/Python/pythonrun.c) at line 193 there is this line PyModule_WarningsModule = PyImport_ImportModule("warnings"); There is no check afterward for any errors. Couldn't a PyErr_Clear() be done so that further statements don't fail because the import of warnings failed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=771097&group_id=5470 From noreply@sourceforge.net Wed Jul 16 04:14:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 20:14:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] IDLE/MAC: Command / Alt Bindings Don't Work Message-ID: Bugs item #768469, was opened at 2003-07-09 08:49 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE/MAC: Command / Alt Bindings Don't Work Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-15 22:14 Message: Logged In: YES user_id=149084 Lib/idlelib: Updated extend.txt (Rev 1.4), help.txt (Rev 1.10), and config-extensions.def (Rev 1.12) to partially correct the issues this bug raised. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-14 20:36 Message: Logged In: YES user_id=149084 I'd like to focus on the bug rather than an RFE for a new keyset. I'd suggest that you use [IDLE Modern] for a couple of months and then post your suggestion to the Idle-dev email list for comment. Please note that the Shift modifier isn't working because there is a bug (already reported on the IDLEfork Tracker). I have asked the IDLEfork Mac expert to take a look at this bug, which is that the Command-[something] bindings don't work (unless they happen to be default Tk bindings). There is also an issue with the use of Alt keys in the extensions. Originally, IDLE had the ability to define extension keybindings for each platform. These were eliminated in IDLEfork with, I believe, the intention to expand the configuration dialog to replace them. However, that has not as yet been accomplished. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 15:39 Message: Logged In: YES user_id=819035 File attachment doesn't seem to be working for me using Mozilla Firebird. Here is the tentative [IDLE Modern] key binding scheme, ordered by virtual event name: [IDLE Modern] beginning-of-line= center-insert= change-indentwidth= close-all-windows= close-window= comment-region= copy= cut= dedent-region= do-nothing= end-of-file= find-again= find-in-files= find-selection= find= goto-line= history-next= history-previous= indent-region= interrupt-execution= newline-and-indent= open-class-browser= open-module= open-new-window= open-window-from-file= paste= plain-newline-and-indent= print-window= python-context-help= python-docs= redo= remove-selection= replace= restart-shell= save-copy-of-window-as-file= save-window-as-file= save-window= select-all= smart-backspace= smart-indent= tabify-region= toggle-auto-coloring= toggle-tabs= uncomment-region= undo= untabify-region= view-restart= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 15:28 Message: Logged In: YES user_id=819035 Proposal for new key binding scheme =================================== Problem ------- Due to several reasons discussed in my previous messages, the 3 available key binding schemes for IDLE in MacOSX are not satisfactory for various reasons, the main one being that the Alt/Option modifier is preempted by MacOSX for accented characters and symbols, and the Command/Apple modifier is preempted by X11 for several shortcuts. Considering that IDLE is supposed to be a tool for beginners as well as for more advanced programmers, the key binding scheme for Windows (which is currently the default scheme) also has a few problems. Although all shortcuts in the [IDLE Classic Windows] key binding scheme seem to work, they use an inconsistent mix of modifier keys that hinders learning and makes it difficult to use in platforms where modifier keys work differently. Most of these shortcuts use the Control and Alt modifiers, but some shortcuts use 2 or more modifiers or a third modifier: Control modifier: close-all-windows= Alt/Meta modifier: close-window= Shift modifier: python-context-help= Several modifiers: redo= save-copy-of-window-as-file= Proposal -------- I propose to use a new key binding scheme that uses one single modifier key for all shortcuts in order to increase learnability and portability. The Control modifier is the natural choice for the standard modifier, since unlike the Alt, Command or Windows modifiers it is not usually used for standard OS shortcuts. I am attaching to this message my ~/.idlerc/config-keys.cfg file containing the bindings for this scheme, which I have tentatively named [IDLE Modern]. My hope is to have this scheme become one of the additional schemes shipped with IDLE, and perhaps even replace the [IDLE Classic Windows] scheme as the default scheme for IDLE on all platforms. Rationale --------- I tried to preserve most bindings that have become common in Mac, Windows and Linux applications, and change non-standard bindings to standard. I have also changed all bindings that use a modifier different from Control, sometimes using a similar binding (e.g. instead of for the <> virtual event), sometimes using a completely different binding. I strived to use only alphabetical keys, numerical keys and function keys, since other characters tend to shift according to which keyboard layout one is using. For instance, in the Portuguese keyboard layout the bracket characters have to accessed using a special modifier key, labeled AltGr (for Alt Graphics) together with a numeric key (AltGr-Key-7 and AltGr-Key-8), while the slash character has to be written using Shift-Key-7. This means that the standard bindings for the <>, <> and <> virtual events are difficult if not impossible to access with a Portuguese keyboard layout. One possible solution, which I chose many years ago, is to memorize the American keyboard layout and use that layout for all programming and command-line work, regardless of the actual labels on your keys. Although not really that difficult, this is a step that most people will understandably refuse to take. A more acceptable solution is to avoid using non-alphanumeric characters, which tend to vary a lot more from one layout to the other. I also tried to bind semantically similar virtual events to neighbouring keys, as is already the case with the standard clipboard shortcuts, which occupy 3 neighbouring keys in the same row (x, c and v). For instance, all find commands are placed sequentially in the same row (f, g, h, j and k). All save commands are placed in neighbouring keys (s, e and r). The dedent and indent events are moved to the same row as 4 other events that affect a region, like comment and uncomment (numeric keys row, 1 to 9), along with some other events associated with tabs. Finally, 2 of the most used virtual events, <> and <>, are now bound to and , which should be much more obvious than and . The old bindings are hard to understand unless you have a history of Emacs ab^H^Huse, and are not as intuitive as using the arrows with a modifier key. Extension bindings ------------------ The key bindings for virtual events belonging to IDLE extensions are currently defined in config-extensions.def and are not customizable directly from IDLE. Since 4 of these virtual events currently use the Alt modifier, they conflict with the above rationale of using one single modifier key for all shortcuts, viz. the Control key. I propose to expand these currents shortcuts with another key bindings that fits in with the proposed [IDLE Modern] scheme: format-paragraph= expand-word= zoom-height= run-module= # unchanged check-module= Binding changes --------------- Comparison of [IDLE Modern] bindings to [IDLE Classic Windows] bindings: a) Identical bindings: beginning-of-line= close-all-windows= # modifier-q is a standard binding for 'quit' in Mac (increasingly used in Windows) copy= # modifier-c is a standard binding 'copy' in Windows and Mac cut= # modifier-x is a standard binding 'cut' in Windows and Mac do-nothing= end-of-file= find= # modifier-f is a standard binding for 'find' in Windows and Mac newline-and-indent= open-new-window= # modifier-n is a standard binding for 'new' in Windows and Mac open-window-from-file= # modifier-o is a standard binding for 'open' in Windows and Mac paste= # modifier-v is a standard binding for 'paste' in Windows and Mac print-window= # modifier-p is a standard binding for 'print' in Windows and Mac python-docs= remove-selection= replace= # modifier-h is a standard binding for 'replace' in Windows and Mac save-window= # modifier-s is a standard binding for 'save' in Windows and Mac select-all= # modifier-a is a standard binding for 'select-all' in Windows and Mac smart-backspace= smart-indent= undo= # modifier-z is a standard binding for 'undo' in Windows and Mac view-restart= b) Similar bindings (Alt or Meta modifier replaced with Control modifier): comment-region= open-module= uncomment-region= tabify-region= untabify-region= c) Changed bindings: center-insert= change-indentwidth= close-window= # modifier-w is a standard binding for 'close-window' in Mac (increasingly used in Windows) dedent-region= find-again= # modifier-g is a standard binding for 'find-again' in Windows and Mac find-in-files= find-selection= goto-line= # modifier-l is a common but not standard binding for 'goto-line' in Windows and Mac history-next= history-previous= indent-region= interrupt-execution= open-class-browser= plain-newline-and-indent= python-context-help= redo= # modifier-y is a common but not standard binding for 'redo' in Windows and Mac restart-shell= save-copy-of-window-as-file= save-window-as-file= toggle-auto-coloring= toggle-tabs= Bindings ordered by key ----------------------- smart-backspace= remove-selection= beginning-of-line= newline-and-indent= smart-indent= python-docs= view-restart= restart-shell= python-context-help= do-nothing= history-previous= history-next= dedent-region= indent-region= comment-region= uncomment-region= tabify-region= untabify-region= change-indentwidth= toggle-tabs= toggle-auto-coloring= select-all= open-class-browser= copy= end-of-file= save-window-as-file= find= find-again= replace= interrupt-execution= find-selection= find-in-files= goto-line= open-module= open-new-window= open-window-from-file= print-window= close-all-windows= save-copy-of-window-as-file= save-window= center-insert= plain-newline-and-indent= paste= close-window= cut= redo= undo= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-12 14:10 Message: Logged In: YES user_id=819035 Thanks for the instructive comments. Here are some answers: 1) The problems are the following: a) The standard key bindings are the IDLE Classic Windows key bindings, which do not work. - None of the many bindings that use the Alt modifier work, since the Alt (a.k.a. Option) key is used in MacOSX for accents and symbols. b) The IDLE Classic Mac key bindings do not work. - Most of them require the Command key, which for some unknown reason do not seem to work. c) The IDLE Classic Unix key bindings mostly work, but are unsatisfactory. - These bindings replace many "chord" key bindings with emacs style shortcuts, which are frankly unpleasant to use for 99% of people not used to emacs. Also, there are still several of these Unix key bindings that use the Alt modifier, and which thus do not work in MacOSX. In spite of all this, it is the most usable of the 3 default schemes. d) 5 key bindings used by extensions are currently not rebindable: Alt-Key-q, Alt-Key-slash, Alt-Key-2, Alt-Key-x and Key-F5. Since 4 of them use the Alt modifier, they do not work under MacOSX e) Some bits of extend.txt and help.txt are outdated. 2) A slightly awkward workaround to problem 1.b: What I meant was that by replacing Command with Meta in key bindings means that many but far from all Command bindings work. By chance, I discovered that using the Control-Command combination instead of just the Command modifier makes most if not all Meta bindings work. It seems as if Meta really is interpreted as Control-Command, with Command working sometimes. This is not very satisfactory, but it's better than any of the other 3 default bindings. 3) Regarding capitalization: I discovered by accident that Tk keybindings are case sensitive. However, all bindings mentioned by me treat capitals and lowercase letters identically, i.e. when I wrote Command-B, I really meant Command-b, and not Command-Shift-b. I'll take care not make that confusion from now on. 4) Command-b and Control-b: The bindings mentioned in my 2003-07-11 18:48 message are Command bindings. Command-b and Command-f really do move to the beginning and end of words, unlike Control-b and Control-f, which move one character back and one character forward. I have no idea why some these Command bindings work, but the fact is they do. 5) It might be useful to get other MacOSX users to check my findings, since there might quirks with my configuration which I'm not aware of. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 15:43 Message: Logged In: YES user_id=149084 Thank you for reporting the issues with help.txt and extend.txt. I will update these files. You are correct about the renaming, extend.txt has not been updated since the new config system was implemented. I agree it would be nice to set the extension configuration from the configuration dialog. However, we are much too close to release to contemplate doing that for 2.3. The extension feature is intended to incorporate 3rd party features so the enhancement of the config dialog would have to be suitably general. Your problem appears to be down to one thing: none of IDLE's "Classic Mac" Command combinations in your config-keys.def work. If I understand you correctly, you are saying that e.g. replacing "Command-Key-w" by "Meta-Key-w" in config-keys.def causes the <> event to work correctly? Note that Tk is very picky about capitalization. "Command-Key-w" is not the same as "Command-Key-W". Please be sure that your file is correct in this regard. If you can get everything working by doing this, would you please upload the modified version of your config-keys.def and let me know what the remaining problems are, if any. In your messages you have variously said that both "Command-B" and "Ctl-b" keystrokes go to the beginning of a word. Is this correct? And do you really mean "Apple/Shift/b" in the first case? The Ctl-b binding and others like it that you have mentioned in your earlier message are part of a number of default Tk bindings that have not been disabled in IDLE. http://www.tcl.tk/man/tcl8.3/TkCmd/text.htm#M141 Clearly, there may not be complete compatibility with this documentation in the Tk Mac implementation. But that is the origin of the bindings. By the way, the way to customize is not to modify config-keys.def, but to modify your .idlerc/config-keys.cfg or any of the other files in that directory. That is what the config dialog does, and it is quite all right to modify it manually as long as you carefully follow the format. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 14:08 Message: Logged In: YES user_id=819035 The file extend.txt references two files that do not exist: keydefs and config.txt I suppose the former corresponds config-keys.def, while the latter has been split into 3 files: config-main.def, config-extensions.def and config-highlight.def. Is this correct? Looking into config-extensions.def, I can finally see were those non-standard key sequences are defined: [FormatParagraph_cfgBindings] format-paragraph= (...) [AutoExpand_cfgBindings] expand-word= (...) [ZoomHeight_cfgBindings] zoom-height= (...) [ScriptBinding_cfgBindings] run-module= check-module= It would nice if these key bindings for extension modules could be put in the same file as the standard key bindings. Even nicer if the configuration dialog could be used to change all key bindings. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 13:48 Message: Logged In: YES user_id=819035 Using the original [IDLE Classic Mac] shortcut keys definitions, the only Command shortcuts that do anything are the following: Command-Q: tries to quit X11 instead of IDLE Command-W: closes X11 windows instead of IDLE windows Command-B: go to beginning of word Command-F: go to end of word Command-D: delete next word Command-H: hide X11 Command-M: minimize window Command-,: X11 preferences dialog ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 13:43 Message: Logged In: YES user_id=819035 Sorry, my confusion. Since I edited my original config-keys.def file, I forgot that the [IDLE Classic Mac] shortcuts used the Command modifier, and not Alt. This confusion is only made in my last message. If you replace "Command" with "Alt" in that message, everything makes sense: """ If I change all keybinding using the Command-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Command, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. """ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 13:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 11:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 11:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 14:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 14:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 11:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 08:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 00:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Wed Jul 16 06:04:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 15 Jul 2003 22:04:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-772091 ] doctest.DocTestSuite does not support __test__ Message-ID: Bugs item #772091, was opened at 2003-07-16 00: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=772091&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: Raymond Hettinger (rhettinger) Assigned to: Tim Peters (tim_one) Summary: doctest.DocTestSuite does not support __test__ Initial Comment: The DocTestSuite tool ignores a module level dictionary named __test__. This limits its usefulness for the current python testsuite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772091&group_id=5470 From noreply@sourceforge.net Wed Jul 16 10:24:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 02:24:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-772176 ] digraphs on komment lines / xlib Message-ID: Bugs item #772176, was opened at 2003-07-16 09:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772176&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Eckersley (daddio_2) Assigned to: Nobody/Anonymous (nobody) Summary: digraphs on komment lines / xlib Initial Comment: Python 2.3 falls over if it encounters non-ascii characters on comment lines. These occur with digraphs and non English names. e.g. This simple program #!/usr/bin/python print 'This program does nothing' # Aber eine Kommentarzeile l�uft nicht! # The " � " causes trouble # This causes Xlib to stop working causes the following output sys:1: DeprecationWarning: Non-ASCII character '\xe4' in file /nglob/g/bat/digraph.py on line 6, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details This program does nothing Some libraries (such as python-xlib 2.2 ) cause this problem. The line parser ought ignore all comment content whether ascii or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772176&group_id=5470 From noreply@sourceforge.net Wed Jul 16 12:43:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 04:43:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors Message-ID: Bugs item #728330, was opened at 2003-04-27 09:21 Message generated for change (Settings changed) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None >Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX, 2.3b1, socketmodule.c compilation errors Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 22: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 14: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 06: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 23: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 17: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 18: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 12: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@sourceforge.net Wed Jul 16 15:19:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 07:19:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-766669 ] Consistent GPF on exit Message-ID: Bugs item #766669, was opened at 2003-07-06 08:32 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 Category: Windows Group: Python 2.2.3 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Kurt Grittner (grittkmg) Assigned to: Mark Hammond (mhammond) Summary: Consistent GPF on exit Initial Comment: Using the following script (clt.py): import os, time, sys from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self. serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient). pack() Button(root, text='Quit All Clients', command=PgmExit). pack() root.mainloop() If you press 'Quit' first, then there are no errors. If you press 'New Client' even once (whether or not there is an echo server to talk to) the program runs the other Toplevel windows seemingly without problems, but then when you press 'Quit' you die in the following place : /* Vc98\Crt\Src\Crtexe.c */ #ifdef WPRFLAG __winitenv = envp; mainret = wmain(argc, argv, envp); #else /* WPRFLAG */ __initenv = envp; mainret = main(argc, argv, envp); #endif /* WPRFLAG */ #endif /* _WINMAIN_ */ /* ------------------------------------------------------- ----------------- */ /* Error executing following line */ exit(mainret); /* ------------------------------------------------------- ----------------- */ /* OS error dump PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=10e7 EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: /* Vc98\Crt\Src\Crt0dat.c */ /* First debug run */ 1020ACE0 jmp doexit+0B6h (1020acf6) 384: } 385: 386: 387: _C_Exit_Done = TRUE; 1020ACE2 mov dword ptr [__C_Exit_Done (10264728)],1 388: 389: ExitProcess(code); 1020ACEC mov ecx,dword ptr [code] 1020ACEF push ecx /* ------------------------------------------------------- ----------------- */ /* Error on the following call */ 1020ACF0 call dword ptr [__imp__ExitProcess@4 (10256020)] /* ------------------------------------------------------- ----------------- */ /* Second debug run */ PYTHON_D caused an invalid page fault in module KERNEL32.DLL at 017f:bff88396. Registers: EAX=c00309c4 CS=017f EIP=bff88396 EFLGS=00210216 EBX=0062ffec SS=0187 ESP=0052fecc EBP=00530044 ECX=00000000 DS=0187 ESI=00000000 FS=1b3f EDX=bff76855 ES=0187 EDI=bff79060 GS=0000 Bytes at CS:EIP: 53 56 57 8b 75 10 8b 38 33 db 85 f6 75 2d 8d b5 Stack dump: 390: 391: 392: } 1020ACF6 mov esp,ebp 1020ACF8 pop ebp 1020ACF9 ret /* Vc98\Crt\Src\Crtexe.c - Continued */ */ } __except ( _XcptFilter(GetExceptionCode(), GetExceptionInformation()) ) { /* * Should never reach here */ _exit( GetExceptionCode() ); } /* end of try - except */ } It seems weird that everything else in the program works fine right up to ExitProcess. The error occurs on multiple windows machines. The error does NOT occur on linux running the same code base. Also, many other multi-threaded sample programs from other authors exhibit the same 'crash on exit' syndrome. Thanks for your attention, Kurt ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-16 10:19 Message: Logged In: YES user_id=31435 Much thanks for following up on this, Mark. I always love it when a new class of races is uncovered by a faster machine than I have . ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-09 00:58 Message: Logged In: YES user_id=14198 Checking in socketmodule.c; new revision: 1.270; previous revision: 1.269 ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-08 07:23 Message: Logged In: YES user_id=816888 Yes! Changing: atexit(NTcleanup); to: Py_AtExit(NTcleanup); Fixes my nasty GPF! Thanks! By the way, the bad behavior isn't limited to GPF's. On every machine that I tested the echo server received a 'connection reset by peer' error instead of the orderly close that running WSACleanup() from the DLL context provides. I missed the presence of Py_AtExit()... much cleaner than my nasty hack. This is a really cool program. My compliments to the chefs. Kurt ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-08 00:35 Message: Logged In: YES user_id=14198 I also can't repro this, but do believe it. I think the patch is simple: RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v retrieving revision 1.268 diff -r1.268 socketmodule.c 3292c3292 < atexit(os_cleanup); --- > Py_AtExit(os_cleanup); This will cause the cleanup function to be called during Py_Finalize(), which is never implicitly called in a DllMain. Can you let me know if this fixes it? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 14:05 Message: Logged In: YES user_id=816888 From: "Eugene Gershnik [SDK MVP]" References: <6hvigvgnlsqhihobl06jt1edjfsv7r4pja@4ax.com> Subject: Re: WSAStartup and WSACleanup from within a DLL Date: Mon, 7 Jul 2003 10:26:25 -0700 Lines: 24 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: Newsgroups: microsoft.public.win32.programmer.networks NNTP-Posting-Host: dsl093-033-235.snd1.dsl.speakeasy.net 66.93.33.235 Path: TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl Xref: TK2MSFTNGP08.phx.gbl microsoft.public.win32. programmer.networks:43932 It is in general a bad idea. atexit() handlers are running from within DLL_PROCESS_DETACH notification and this is a bad place to clean up other DLLs. See remarks to DllMain in MSDN for details. Note that it is also a bad idea to use C++ global or static objects to startup/cleanup winsock since those als rely on atexit() for destruction. The best way to init winsock for your DLL is to have something like MyDllInit() and MyDllTerm() functions that should be called be the user of the DLL. Eugene Kurt Grittner wrote: > Hello Group, > > If you call all of your socket functions from within a DLL, and you > do the WSAStartup() inside the DLL, is it legal to then have your > WSACleanup() run via atexit(StaticFunctionInDLL)? I am getting > weird behavior (GPF) on someone else's program when they do this. > The WSACleanup ends up getting called from crt0dat. Any Opinions? > > Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 05:34 Message: Logged In: YES user_id=816888 Here is a small windows project that causes the error for me on my faster machines. I will try it on a bunch of other machines. badsock good Runs it the good way badsock bad or just plain badsock Causes the error for me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 02:13 Message: Logged In: YES user_id=816888 Well, Python is new to me, but Win32 isn't. My theory for why it fails is simply that the program breaks the rules and creates a window for failure. On my system the window is large. On yours, the window is smaller. This is a machine with lots of memory. (AMD XP2000, 512MB RAM). It has a new hard drive with an on board 8MB cache. Things happen fast on this machine. This single fact could explain why the failure condition always wins the race for me. The machines at work (which also fail) are similar. Who puts win98SE on a brand new machine these days? Hmmm... maybe not too many people. I can turn your argument around... I have dozens of network programs running on this machine, many of which I wrote, none of which play fast-and-loose with threaded-DLL's, all of which work. Python is the only network program that fails. It fails every single time. I luckily have access to the source, so I can find the bug and fix it. Great! The wonders of open source. Well, anyhow, I was only trying to lend a hand. Python looks promising. I am looking at it as a potential replacement for VB/ActiveX. I am going to try this on some older, slower machines. Also, I will attempt to code a demo program that reproduces the bad behavior by duplicating the steps taken in the socketmodule, and hopefully also duplicating the error on more machines. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-07 00:26 Message: Logged In: YES user_id=31435 Mark, can you take a look at this? If you agree the design is hosed, it would be good to fix it before 2.3r1. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-07 00:21 Message: Logged In: YES user_id=31435 You're trying too hard . I'm not arguing about the design (for one thing, it's not my design, and I don't know anything about it), I'm wondering both why I can't reproduce a problem, and especially why no other report of this has ever been made. You surely don't believe you're the only programmer to try sockets in Python on Windows, right? I also tried it under an up-to-date Win98SE, also with MSVC 6 and all current IE 6 patches. Indeed, that's the machine I've built the PythonLabs Windows installer *on* for the last two years. No problem. Everyone who has ever run the Python test suite on Windows has exercised sockets on Windows, and so has anyone who has ever run Zope on Windows, etc. It may indeed be a bit of Rocket Science if you don't have a theory for why it fails only when you run it! The reason I'm keen to know is that only someone who can see the problem can test a putative fix (and so confirm-- or refute --that the problem goes away). ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-07 00:00 Message: Logged In: YES user_id=816888 Umm, this is not rocket science. WSACleanup() is being called in the wrong context. Startup is called in a DLL context. That puts the info in Thread Local Storage (TLS). The DLL Is allowed to unload with an atexit() pointer still pending to it. This is bad design. You should always call startup/cleanup in pairs and in the same thread context. As I said before this happens on every win98SE machine that I have tried it on. I have no firewall or virus scanner. This is a fairly recent installation of win98 with all of the MS updates for I.E. Apart from that, the most unusual thing is the presence of the VisualStudio 6.0 suite of programs. I can do a new install of win98SE on an old machine, just out of curiosity, but you only have to read this web site to see that this design for startup/cleanup calls is a recipie for disaster: http://support.microsoft.com/default.aspx?scid=http: //support.microsoft.com:80/support/kb/articles/Q237/5/72. ASP&NoWebContent=1 Here is a list of some of the modules running on my machine: USER32.DLL 4.10.2227 Microsoft Corporation Win32 USER32 core component C:\WINDOWS\SYSTEM\USER32. DLL 4/21/00 3:33:18 PM GMT Microsoft(R) Windows(R) Operating System bfc00000 - bfc11000 GDI32.DLL 4.10.1998 Microsoft Corporation Win32 GDI core component C:\WINDOWS\SYSTEM\GDI32. DLL 4/23/98 4:24:18 AM GMT Microsoft(R) Windows(R) Operating System bff20000 - bff46000 ADVAPI32.DLL 4.80.1675 Microsoft Corporation Win32 ADVAPI32 core component C: \WINDOWS\SYSTEM\ADVAPI32.DLL 4/23/99 4:37:33 PM GMT Microsoft(R) Windows(R) Operating System bfe80000 - bfe90000 KERNEL32.DLL 4.10.2222 Microsoft Corporation Win32 Kernel core component C: \WINDOWS\SYSTEM\KERNEL32.DLL 4/23/99 12:45:39 AM GMT Microsoft(R) Windows(R) Operating System bff70000 - bffe3000 MPR.DLL 4.10.1998 Microsoft Corporation WIN32 Network Interface DLL C:\WINDOWS\SYSTEM\MPR. DLL 4/23/99 4:37:36 PM GMT Microsoft(R) Windows(R) Operating System 7fbf0000 - 7fbfe000 MSNP32.DLL 4.10.2222 Microsoft Corporation Network provider for Microsoft networks C:\WINDOWS\SYSTEM\MSNP32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fb20000 - 7fb34000 MSNET32.DLL 4.10.2224 Microsoft Corporation Microsoft 32-bit Network API Library C: \WINDOWS\SYSTEM\MSNET32.DLL 11/12/99 4:15:15 AM GMT Microsoft(R) Windows(R) Operating System 7f300000 - 7f313000 MPREXE.EXE 4.10.1998 Microsoft Corporation WIN32 Network Interface Service Process C:\WINDOWS\SYSTEM\MPREXE.EXE 4/23/98 2:19:38 AM GMT Microsoft(R) Windows(R) Operating System 00500000 - 00507000 MPRSERV.DLL 4.10.2222 Microsoft Corporation Multinet Router C: \WINDOWS\SYSTEM\MPRSERV.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7fad0000 - 7faf6000 NETAPI32.DLL 4.10.1998 Microsoft Corporation 32-bit network API DLL C: \WINDOWS\SYSTEM\NETAPI32.DLL 4/23/99 4:37:37 PM GMT Microsoft(R) Windows(R) Operating System 7f990000 - 7f995000 NETBIOS.DLL C:\WINDOWS\SYSTEM\NETBIOS. DLL 4/23/99 4:37:39 PM GMT 7f840000 - 7f848000 RNR20.DLL 4.10.2222 Microsoft Corporation Windows Socket2 NameSpace DLL C: \WINDOWS\SYSTEM\RNR20.DLL 4/23/99 4:38:44 PM GMT Microsoft(R) Windows(R) Operating System 783c0000 - 783cf000 MSAFD.DLL 4.10.1998 Microsoft Corporation Microsoft Windows Sockets 2.0 Service Provider C:\WINDOWS\SYSTEM\MSAFD.DLL 4/23/99 4: 38:11 PM GMT Microsoft(R) Windows(R) Operating System 7b410000 - 7b41b000 RPCLTSCM.DLL 4.71.2900 Microsoft Corporation Remote Process Control LTSCM DLL C: \WINDOWS\SYSTEM\RPCLTSCM.DLL 4/23/99 4:38:45 PM GMT Microsoft® Windows® Operating System 78320000 - 7832a000 WSOCK32.DLL 4.10.1998 Microsoft Corporation BSD Socket API for Windows C: \WINDOWS\SYSTEM\WSOCK32.DLL 4/23/99 4:39:14 PM GMT Microsoft(R) Windows(R) Operating System 75fa0000 - 75faa000 MSWSOCK.DLL 4.10.2222 Microsoft Corporation Microsoft WinSock Extension APIs C: \WINDOWS\SYSTEM\MSWSOCK.DLL 4/23/99 4:38:30 PM GMT Microsoft(R) Windows(R) Operating System 794d0000 - 794e5000 WS2_32.DLL 4.10.2222 Microsoft Corporation Windows Socket 2.0 32-Bit DLL C: \WINDOWS\SYSTEM\WS2_32.DLL 4/23/99 4:39:13 PM GMT Microsoft(R) Windows(R) Operating System 76000000 - 76012000 WS2HELP.DLL 4.10.1998 Microsoft Corporation Windows Socket 2.0 Helper for Windows 98 C:\WINDOWS\SYSTEM\WS2HELP.DLL 4/23/99 4: 39:13 PM GMT Microsoft(R) Windows(R) Operating System 75fe0000 - 75fe6000 DIGEST.DLL 6.00.2800.1106 Microsoft Corporation Digest SSPI Authentication Package C: \WINDOWS\SYSTEM\DIGEST.DLL 8/29/02 11:21:08 AM GMT Microsoft® Windows® Operating System 007a0000 - 007b0000 MSNSSPC.DLL 6.00.7753 Microsoft Corporation MSN Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSNSSPC.DLL 4/23/99 4:38:21 PM GMT Microsoft® Internet Services 7a210000 - 7a22f000 MSAPSSPC.DLL 5.00.7729 Microsoft Corporation DPA Client for 32 bit platforms C: \WINDOWS\SYSTEM\MSAPSSPC.DLL 4/23/99 4:38:11 PM GMT Microsoft® Internet Services 7b3f0000 - 7b401000 MSVCRT40.DLL 4.22.0000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT40.DLL 4/23/99 4:38:29 PM GMT Microsoft® Visual C++ 79660000 - 796b5000 SECUR32.DLL 4.10.2222 Microsoft Corporation Microsoft Win32 Security Services C: \WINDOWS\SYSTEM\SECUR32.DLL 4/23/99 4:37:39 PM GMT Microsoft(R) Windows(R) Operating System 7f870000 - 7f87a000 RPCSS.EXE 4.71.2900 Microsoft Corporation Distributed COM Services C: \WINDOWS\SYSTEM\RPCSS.EXE 9/1/98 6:18:39 PM GMT Microsoft(R) Windows NT(TM) Operating System 01000000 - 01005000 MSVCRT20.DLL 2.11.000 Microsoft Corporation Microsoft® C Runtime Library C: \WINDOWS\SYSTEM\MSVCRT20.DLL 4/23/99 4:37:36 PM GMT Microsoft® Visual C++ 7fc30000 - 7fc75000 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 23:13 Message: Logged In: YES user_id=31435 Kurt, which versions of Windows and winsock.dll are you using? I continue to be unable to reproduce any problem here, and there have been no other reports of this despite thousands of Python programs using sockets on Windows for a decade. I have to conclude there's something unique in your setup. FYI, sometimes virus scanners and/or "personal firewalls" cause bizarre crashes during startup or shutdown. Are you running one (or more) of those? ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 21:29 Message: Logged In: YES user_id=816888 I have a working fix for this problem, but the code is a fairly ugly hack. (A terrible thing to do to such a well organized codebase). 1. I exported a fini_socket() function from the PYD DLL. 2. I cloned the dynamic lookup function to check for the optional fini_socket() name as well as the init_socket(). If found, I remember it in a global. 3. In PyImport_Cleanup() I call the fini_socket() routine (if present) before these modules start getting freed. 4. In NTInit() I add to a counter instead of using atexit() 5. fini_socket() calls NTcleanup(), which simply calls WSACleanup 'counter' times to release the winsock DLL. This works, so now I can go on with my Python study. If anyone wants my hack code, just email me. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 16:57 Message: Logged In: YES user_id=816888 The minimum required to cause this GPF is the following: C:\ptest>python Python 2.3b2 (#43, Jun 29 2003, 16:43:04) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from socket import * >>> s=socket(AF_INET, SOCK_STREAM) >>> I have found the problem in the source, though I don't know how to fix it. WSAStartup() is called as a DLL export, but the WSACleanup() is called as an atexit(). This is too late to call it. It must be called before the DLL unloads, or the WSAStartup should be moved to the process level. I don't know the program well enough to attempt a hack, but I did verify that it is the WSACleanup line running from the CRT code that is killing things (every time you even create a socket). Notice, this is using the latest version too. Kurt ---------------------------------------------------------------------- Comment By: Kurt Grittner (grittkmg) Date: 2003-07-06 14:41 Message: Logged In: YES user_id=816888 Hi Tim, Here is some more info. I stripped out all references to socket, and saved as clt2.clw to force it to load with pythonw.exe. Things worked perfectly. Here is the script: import os, time, sys #from socket import * from Tkinter import * class App: def __init__(self, master): self.win = Toplevel(master) self.button = Button(self.win, text="QUIT", fg="red", command=self.goaway) self.button.pack(side=LEFT) self.hi_there = Button(self.win, text="Hello", command=self.say_hi) self.hi_there.pack(side=LEFT) #self.serverHost = 'localhost' self.serverHost = '192.168.1.12' self.serverPort = 50007 #self.sockobj = socket(AF_INET, SOCK_STREAM) #self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] #for line in self.message: # self.sockobj.send(line) #data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): #self.sockobj.shutdown(0) #self.sockobj.close() self.win.destroy() def NewClient(): App(root) def PgmExit(): root.quit() root = Tk() Button(root, text='New Client', command=NewClient).pack() Button(root, text='Quit All Clients', command=PgmExit).pack() root.mainloop() So next, I did the reverse... I took out all references to Tkinter and saved it as clt3.clw (again to use pythonw.exe). It blew sky high again. Here's the script: import os, time, sys from socket import * class App: def __init__(self, master): self.serverHost = '192.168.1.12' self.serverPort = 50007 self.sockobj = socket(AF_INET, SOCK_STREAM) self.sockobj.connect((self.serverHost, self.serverPort)) def say_hi(self): self.message = ['Hello network world'] for line in self.message: self.sockobj.send(line) data = self.sockobj.recv(1024) print 'Client received:', `data` def goaway(self): self.sockobj.shutdown(0) self.sockobj.close() x = App(0) x.say_hi() time.sleep(1) y = App(1) y.say_hi() time.sleep(1) x.goaway() y.goaway() time.sleep(1) Here's the output from the linux-based echo server: ns1:/www/python # python select-server.py select-server loop starting Connect: ('192.168.1.20', 2382) 135755344 got Hello network world on 135755344 Connect: ('192.168.1.20', 2383) 135744224 got Hello network world on 135744224 got on 135755344 got on 135744224 Here's the (now familiar) GPF output: PYTHONW caused an invalid page fault in module KERNEL32.DLL at 017f:bff7b9a6. Registers: EAX=00000000 CS=017f EIP=bff7b9a6 EFLGS=00000246 EBX=007961a0 SS=0187 ESP=0095fba8 EBP=0095fbe8 ECX=0095fbf8 DS=0187 ESI=10013168 FS=19d7 EDX=0079d670 ES=0187 EDI=0079e7b0 GS=356e Bytes at CS:EIP: ff 76 04 e8 13 89 ff ff 5e c2 04 00 56 8b 74 24 Stack dump: 007961a0 10007eb0 10013168 7800b317 0079eb50 0079d670 00000000 007a2c98 00000000 81dafb90 00794641 760028e8 0079d67c 0079d670 007961a0 0079d67c And here's the netstat output from right after the crash: C:\WINDOWS>netstat /a Active Connections Proto Local Address Foreign Address State TCP amd2000:2339 AMD2000:0 LISTENING TCP amd2000:135 AMD2000:0 LISTENING TCP amd2000:1243 AMD2000:0 LISTENING TCP amd2000:1025 AMD2000:0 LISTENING TCP amd2000:1699 AMD2000:0 LISTENING TCP amd2000:2339 www.mlgames.org:22 ESTABLISHED TCP amd2000:2382 www.mlgames.org:50007 TIME_WAIT TCP amd2000:2383 www.mlgames.org:50007 TIME_WAIT TCP amd2000:137 AMD2000:0 LISTENING TCP amd2000:138 AMD2000:0 LISTENING TCP amd2000:nbsession AMD2000:0 LISTENING TCP amd2000:1243 www.mlgames.org:22 ESTABLISHED UDP amd2000:1699 *:* UDP amd2000:nbname *:* UDP amd2000:nbdatagram *:* C:\WINDOWS> Notice the TIME_WAIT connections to port 50007. It looks like this is a 'socket' library problem. I also tried adding del x del y and a long delay to the end of the script to see if things would change... but no. Same explosion. So, to answer your question. It happens on both python and pythonw, and it happens without loading Tkinter. I suppose I can try the latest development version as you suggested. Kurt ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-06 12:34 Message: Logged In: YES user_id=31435 Unassigned. Didn't see any problem on Win98SE, under 2.2.3 or 2.3b2, using either of the self.serverHost assignments. If you can, please try under 2.3b2. On Windows that ships with the current version of Tcl/Tk (8.4.3), and some kinds of Tcl/Tk Windows shutdown races are said to be fixed in 8.4.3. Question: How do you start this program? With python.exe or with pythonw.exe? The only known workaround for some kinds of previous Tcl/Tk shutdown races was to start the program with pythonw.exe. So if you haven't tried pythonw.exe, try it and see whether the problem goes away. If it does, it's almost certainly a bug in Tcl/Tk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766669&group_id=5470 From noreply@sourceforge.net Wed Jul 16 16:49:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 08:49:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] IDLE/MAC: Command / Alt Bindings Don't Work Message-ID: Bugs item #768469, was opened at 2003-07-09 13:49 Message generated for change (Comment added) made by tonylownds You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE/MAC: Command / Alt Bindings Don't Work Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2003-07-16 15:49 Message: Logged In: YES user_id=24100 [tiagoh] >Using Apple's X11 beta 3 version, I am unable to access >any of the shortcuts that use the Alt key, including >the history keystrokes that recall past commands. >... >Is there any way to bypass this, allowing the Alt key >to be handled directly by IDLE? So, IDLE is running under X11? Perhaps you can bypass the undesirable behavior by changing the configuration of the X11 server. IDLE can not do anything to help in your situation, AFAIK, as it is X11 that is not giving the keystrokes to Tk. Have you tried using the native-windowing- system version of Tk, instead of Tk through X11? Mac keys bindings work smoothly, you can even override bindings if you like. [tiagoh again] >Unless I'm doing something stupid, this would be a serious >defect with respect to IDLE usability under MacOSX It is a serious defect to usability with respect to IDLE usability under MacOSX *under X11*. That is a big difference. Perhaps some information about using native Tk instead of through X11 would be good to add. Unless I am missing something about your software setup. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-16 03:14 Message: Logged In: YES user_id=149084 Lib/idlelib: Updated extend.txt (Rev 1.4), help.txt (Rev 1.10), and config-extensions.def (Rev 1.12) to partially correct the issues this bug raised. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-15 01:36 Message: Logged In: YES user_id=149084 I'd like to focus on the bug rather than an RFE for a new keyset. I'd suggest that you use [IDLE Modern] for a couple of months and then post your suggestion to the Idle-dev email list for comment. Please note that the Shift modifier isn't working because there is a bug (already reported on the IDLEfork Tracker). I have asked the IDLEfork Mac expert to take a look at this bug, which is that the Command-[something] bindings don't work (unless they happen to be default Tk bindings). There is also an issue with the use of Alt keys in the extensions. Originally, IDLE had the ability to define extension keybindings for each platform. These were eliminated in IDLEfork with, I believe, the intention to expand the configuration dialog to replace them. However, that has not as yet been accomplished. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 20:39 Message: Logged In: YES user_id=819035 File attachment doesn't seem to be working for me using Mozilla Firebird. Here is the tentative [IDLE Modern] key binding scheme, ordered by virtual event name: [IDLE Modern] beginning-of-line= center-insert= change-indentwidth= close-all-windows= close-window= comment-region= copy= cut= dedent-region= do-nothing= end-of-file= find-again= find-in-files= find-selection= find= goto-line= history-next= history-previous= indent-region= interrupt-execution= newline-and-indent= open-class-browser= open-module= open-new-window= open-window-from-file= paste= plain-newline-and-indent= print-window= python-context-help= python-docs= redo= remove-selection= replace= restart-shell= save-copy-of-window-as-file= save-window-as-file= save-window= select-all= smart-backspace= smart-indent= tabify-region= toggle-auto-coloring= toggle-tabs= uncomment-region= undo= untabify-region= view-restart= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 20:28 Message: Logged In: YES user_id=819035 Proposal for new key binding scheme =================================== Problem ------- Due to several reasons discussed in my previous messages, the 3 available key binding schemes for IDLE in MacOSX are not satisfactory for various reasons, the main one being that the Alt/Option modifier is preempted by MacOSX for accented characters and symbols, and the Command/Apple modifier is preempted by X11 for several shortcuts. Considering that IDLE is supposed to be a tool for beginners as well as for more advanced programmers, the key binding scheme for Windows (which is currently the default scheme) also has a few problems. Although all shortcuts in the [IDLE Classic Windows] key binding scheme seem to work, they use an inconsistent mix of modifier keys that hinders learning and makes it difficult to use in platforms where modifier keys work differently. Most of these shortcuts use the Control and Alt modifiers, but some shortcuts use 2 or more modifiers or a third modifier: Control modifier: close-all-windows= Alt/Meta modifier: close-window= Shift modifier: python-context-help= Several modifiers: redo= save-copy-of-window-as-file= Proposal -------- I propose to use a new key binding scheme that uses one single modifier key for all shortcuts in order to increase learnability and portability. The Control modifier is the natural choice for the standard modifier, since unlike the Alt, Command or Windows modifiers it is not usually used for standard OS shortcuts. I am attaching to this message my ~/.idlerc/config-keys.cfg file containing the bindings for this scheme, which I have tentatively named [IDLE Modern]. My hope is to have this scheme become one of the additional schemes shipped with IDLE, and perhaps even replace the [IDLE Classic Windows] scheme as the default scheme for IDLE on all platforms. Rationale --------- I tried to preserve most bindings that have become common in Mac, Windows and Linux applications, and change non-standard bindings to standard. I have also changed all bindings that use a modifier different from Control, sometimes using a similar binding (e.g. instead of for the <> virtual event), sometimes using a completely different binding. I strived to use only alphabetical keys, numerical keys and function keys, since other characters tend to shift according to which keyboard layout one is using. For instance, in the Portuguese keyboard layout the bracket characters have to accessed using a special modifier key, labeled AltGr (for Alt Graphics) together with a numeric key (AltGr-Key-7 and AltGr-Key-8), while the slash character has to be written using Shift-Key-7. This means that the standard bindings for the <>, <> and <> virtual events are difficult if not impossible to access with a Portuguese keyboard layout. One possible solution, which I chose many years ago, is to memorize the American keyboard layout and use that layout for all programming and command-line work, regardless of the actual labels on your keys. Although not really that difficult, this is a step that most people will understandably refuse to take. A more acceptable solution is to avoid using non-alphanumeric characters, which tend to vary a lot more from one layout to the other. I also tried to bind semantically similar virtual events to neighbouring keys, as is already the case with the standard clipboard shortcuts, which occupy 3 neighbouring keys in the same row (x, c and v). For instance, all find commands are placed sequentially in the same row (f, g, h, j and k). All save commands are placed in neighbouring keys (s, e and r). The dedent and indent events are moved to the same row as 4 other events that affect a region, like comment and uncomment (numeric keys row, 1 to 9), along with some other events associated with tabs. Finally, 2 of the most used virtual events, <> and <>, are now bound to and , which should be much more obvious than and . The old bindings are hard to understand unless you have a history of Emacs ab^H^Huse, and are not as intuitive as using the arrows with a modifier key. Extension bindings ------------------ The key bindings for virtual events belonging to IDLE extensions are currently defined in config-extensions.def and are not customizable directly from IDLE. Since 4 of these virtual events currently use the Alt modifier, they conflict with the above rationale of using one single modifier key for all shortcuts, viz. the Control key. I propose to expand these currents shortcuts with another key bindings that fits in with the proposed [IDLE Modern] scheme: format-paragraph= expand-word= zoom-height= run-module= # unchanged check-module= Binding changes --------------- Comparison of [IDLE Modern] bindings to [IDLE Classic Windows] bindings: a) Identical bindings: beginning-of-line= close-all-windows= # modifier-q is a standard binding for 'quit' in Mac (increasingly used in Windows) copy= # modifier-c is a standard binding 'copy' in Windows and Mac cut= # modifier-x is a standard binding 'cut' in Windows and Mac do-nothing= end-of-file= find= # modifier-f is a standard binding for 'find' in Windows and Mac newline-and-indent= open-new-window= # modifier-n is a standard binding for 'new' in Windows and Mac open-window-from-file= # modifier-o is a standard binding for 'open' in Windows and Mac paste= # modifier-v is a standard binding for 'paste' in Windows and Mac print-window= # modifier-p is a standard binding for 'print' in Windows and Mac python-docs= remove-selection= replace= # modifier-h is a standard binding for 'replace' in Windows and Mac save-window= # modifier-s is a standard binding for 'save' in Windows and Mac select-all= # modifier-a is a standard binding for 'select-all' in Windows and Mac smart-backspace= smart-indent= undo= # modifier-z is a standard binding for 'undo' in Windows and Mac view-restart= b) Similar bindings (Alt or Meta modifier replaced with Control modifier): comment-region= open-module= uncomment-region= tabify-region= untabify-region= c) Changed bindings: center-insert= change-indentwidth= close-window= # modifier-w is a standard binding for 'close-window' in Mac (increasingly used in Windows) dedent-region= find-again= # modifier-g is a standard binding for 'find-again' in Windows and Mac find-in-files= find-selection= goto-line= # modifier-l is a common but not standard binding for 'goto-line' in Windows and Mac history-next= history-previous= indent-region= interrupt-execution= open-class-browser= plain-newline-and-indent= python-context-help= redo= # modifier-y is a common but not standard binding for 'redo' in Windows and Mac restart-shell= save-copy-of-window-as-file= save-window-as-file= toggle-auto-coloring= toggle-tabs= Bindings ordered by key ----------------------- smart-backspace= remove-selection= beginning-of-line= newline-and-indent= smart-indent= python-docs= view-restart= restart-shell= python-context-help= do-nothing= history-previous= history-next= dedent-region= indent-region= comment-region= uncomment-region= tabify-region= untabify-region= change-indentwidth= toggle-tabs= toggle-auto-coloring= select-all= open-class-browser= copy= end-of-file= save-window-as-file= find= find-again= replace= interrupt-execution= find-selection= find-in-files= goto-line= open-module= open-new-window= open-window-from-file= print-window= close-all-windows= save-copy-of-window-as-file= save-window= center-insert= plain-newline-and-indent= paste= close-window= cut= redo= undo= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-12 19:10 Message: Logged In: YES user_id=819035 Thanks for the instructive comments. Here are some answers: 1) The problems are the following: a) The standard key bindings are the IDLE Classic Windows key bindings, which do not work. - None of the many bindings that use the Alt modifier work, since the Alt (a.k.a. Option) key is used in MacOSX for accents and symbols. b) The IDLE Classic Mac key bindings do not work. - Most of them require the Command key, which for some unknown reason do not seem to work. c) The IDLE Classic Unix key bindings mostly work, but are unsatisfactory. - These bindings replace many "chord" key bindings with emacs style shortcuts, which are frankly unpleasant to use for 99% of people not used to emacs. Also, there are still several of these Unix key bindings that use the Alt modifier, and which thus do not work in MacOSX. In spite of all this, it is the most usable of the 3 default schemes. d) 5 key bindings used by extensions are currently not rebindable: Alt-Key-q, Alt-Key-slash, Alt-Key-2, Alt-Key-x and Key-F5. Since 4 of them use the Alt modifier, they do not work under MacOSX e) Some bits of extend.txt and help.txt are outdated. 2) A slightly awkward workaround to problem 1.b: What I meant was that by replacing Command with Meta in key bindings means that many but far from all Command bindings work. By chance, I discovered that using the Control-Command combination instead of just the Command modifier makes most if not all Meta bindings work. It seems as if Meta really is interpreted as Control-Command, with Command working sometimes. This is not very satisfactory, but it's better than any of the other 3 default bindings. 3) Regarding capitalization: I discovered by accident that Tk keybindings are case sensitive. However, all bindings mentioned by me treat capitals and lowercase letters identically, i.e. when I wrote Command-B, I really meant Command-b, and not Command-Shift-b. I'll take care not make that confusion from now on. 4) Command-b and Control-b: The bindings mentioned in my 2003-07-11 18:48 message are Command bindings. Command-b and Command-f really do move to the beginning and end of words, unlike Control-b and Control-f, which move one character back and one character forward. I have no idea why some these Command bindings work, but the fact is they do. 5) It might be useful to get other MacOSX users to check my findings, since there might quirks with my configuration which I'm not aware of. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 20:43 Message: Logged In: YES user_id=149084 Thank you for reporting the issues with help.txt and extend.txt. I will update these files. You are correct about the renaming, extend.txt has not been updated since the new config system was implemented. I agree it would be nice to set the extension configuration from the configuration dialog. However, we are much too close to release to contemplate doing that for 2.3. The extension feature is intended to incorporate 3rd party features so the enhancement of the config dialog would have to be suitably general. Your problem appears to be down to one thing: none of IDLE's "Classic Mac" Command combinations in your config-keys.def work. If I understand you correctly, you are saying that e.g. replacing "Command-Key-w" by "Meta-Key-w" in config-keys.def causes the <> event to work correctly? Note that Tk is very picky about capitalization. "Command-Key-w" is not the same as "Command-Key-W". Please be sure that your file is correct in this regard. If you can get everything working by doing this, would you please upload the modified version of your config-keys.def and let me know what the remaining problems are, if any. In your messages you have variously said that both "Command-B" and "Ctl-b" keystrokes go to the beginning of a word. Is this correct? And do you really mean "Apple/Shift/b" in the first case? The Ctl-b binding and others like it that you have mentioned in your earlier message are part of a number of default Tk bindings that have not been disabled in IDLE. http://www.tcl.tk/man/tcl8.3/TkCmd/text.htm#M141 Clearly, there may not be complete compatibility with this documentation in the Tk Mac implementation. But that is the origin of the bindings. By the way, the way to customize is not to modify config-keys.def, but to modify your .idlerc/config-keys.cfg or any of the other files in that directory. That is what the config dialog does, and it is quite all right to modify it manually as long as you carefully follow the format. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 19:08 Message: Logged In: YES user_id=819035 The file extend.txt references two files that do not exist: keydefs and config.txt I suppose the former corresponds config-keys.def, while the latter has been split into 3 files: config-main.def, config-extensions.def and config-highlight.def. Is this correct? Looking into config-extensions.def, I can finally see were those non-standard key sequences are defined: [FormatParagraph_cfgBindings] format-paragraph= (...) [AutoExpand_cfgBindings] expand-word= (...) [ZoomHeight_cfgBindings] zoom-height= (...) [ScriptBinding_cfgBindings] run-module= check-module= It would nice if these key bindings for extension modules could be put in the same file as the standard key bindings. Even nicer if the configuration dialog could be used to change all key bindings. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:48 Message: Logged In: YES user_id=819035 Using the original [IDLE Classic Mac] shortcut keys definitions, the only Command shortcuts that do anything are the following: Command-Q: tries to quit X11 instead of IDLE Command-W: closes X11 windows instead of IDLE windows Command-B: go to beginning of word Command-F: go to end of word Command-D: delete next word Command-H: hide X11 Command-M: minimize window Command-,: X11 preferences dialog ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 18:43 Message: Logged In: YES user_id=819035 Sorry, my confusion. Since I edited my original config-keys.def file, I forgot that the [IDLE Classic Mac] shortcuts used the Command modifier, and not Alt. This confusion is only made in my last message. If you replace "Command" with "Alt" in that message, everything makes sense: """ If I change all keybinding using the Command-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Command, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. """ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 18:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 16:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 19:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 16:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 13:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 05:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Wed Jul 16 17:27:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 09:27:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-769861 ] "make info" croaks Message-ID: Bugs item #769861, was opened at 2003-07-11 16:50 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769861&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: "make info" croaks Initial Comment: I noticed this problem mentioned on the fink list. In the Docs/info directory, executing "make" leads to an Emacs error: % pwd /Users/skip/src/python/head/dist/src/Doc/info % make Using emacs to build the info docs EMACS=emacs ../tools/mkinfo ../lib/lib.tex python-lib.texi python-lib.info emacs -batch -q --no-site-file -l /Users/skip/src/python/ head/dist/src/Doc/tools/py2texi.el --eval (setq py2texi-dirs '("./" "../texinputs/" "/Users/skip/src/python/head/dist/src/ Doc/lib")) --eval (setq py2texi-texi-file-name "python- lib.texi") --eval (setq py2texi-info-file-name "python- lib.info") --eval (py2texi "/Users/skip/src/python/head/dist/ src/Doc/lib/lib.tex") -f kill-emacs Mark set Args out of range: 405571, 405573 make: *** [python-lib.info] Error 255 The regular expression used to match Latex commands will skip over an optional argument, but that argument can't contain a right square bracket. This is okay: \versionchanged[foo bar baz]{2.3} but this is not \versionchanged[foo [bar] baz]{2.3} The \versionchanged macro at the end of libre.tex violates this property. I'm not sure what to do about it since regular expressions can't count nesting depth. A quick hack appears to be to change the search pattern in py2texi-process-commands to "\\\([a-zA-Z*]+\)\(\[[^}]*\]\)?" but I'm not sure what other side-effects that might have on the info file generation. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-16 12:27 Message: Logged In: YES user_id=3066 This particular bug has been fixed in Doc/lib/libre.tex revision 1.101. Other issues remain in the GNU info conversion; still working on those. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=769861&group_id=5470 From noreply@sourceforge.net Wed Jul 16 20:38:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 12:38:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-610401 ] linuxaudiodev not documented Message-ID: Bugs item #610401, was opened at 2002-09-17 03:31 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610401&group_id=5470 Category: Documentation >Group: Feature Request >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Alexandre Fayolle (afayolle) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: linuxaudiodev not documented Initial Comment: Hi, I've just discovered that there is a linuxaudiodev module in python, which is not mentioned in the standard library documentation. While it looks a lot like sunaudiodev, which is documented, the sunaudiodev docs cannot be used directly because both modules don't share the same interfaces. For instance open() does not accept the same parameters, and the audio device objects don't have the same methods. Having some docstrings in the linuxaudiodev module could help a lot. Cheers, Alexandre ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-16 15:38 Message: Logged In: YES user_id=3066 linuxaudiodev is deprecated and ossaudiodev has been documented; closing this report as "Won't Fix". ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-21 01:56 Message: Logged In: YES user_id=357491 Should we close this since linuxaudiodev has been deprecated? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-01-07 20:02 Message: Logged In: YES user_id=33168 Note: linuxaudiodev has been deprecated. ossaudiodev is the module which should be documented. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2002-09-17 10:05 Message: Logged In: YES user_id=3066 There's also an "audiodev" module, which masks the differences between the SGI interface (the "al" and "AL" modules) and the Solaris interface ("sunaudiodev"). Probably the right thing would be for someone who understands the linuxaudiodev interface to extend the "audiodev" module to support Linux as well, and then we could document the audiodev interface instead, and treat the others as implementation details. But I know almost nothing about audio beyond how to stick a CD in a CD player. Contributions are welcome. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=610401&group_id=5470 From noreply@sourceforge.net Wed Jul 16 22:08:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 14:08:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-764504 ] doctest fails with TypeError Message-ID: Bugs item #764504, was opened at 2003-07-02 06:30 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764504&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark J (average) >Assigned to: Raymond Hettinger (rhettinger) Summary: doctest fails with TypeError Initial Comment: #mymod.py: class base(dict): myupdate = dict.update #FINE def myfunc(self): pass class derive(base): myname = base.myfunc #FAILS import doctest, mymod doctest.testmod(mymod) ****** $ python2.3b2 mymod.py Traceback (most recent call last): File "mymod.py", line 8, in ? import doctest, mymod File "/home/me/mymod.py", line 9, in ? doctest.testmod(mymod) File "/usr/local/lib/python2.3/doctest.py", line 1137, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/local/lib/python2.3/doctest.py", line 900, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/local/lib/python2.3/doctest.py", line 1061, in __runone return self.rundoc(target, name) File "/usr/local/lib/python2.3/doctest.py", line 820, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/local/lib/python2.3/doctest.py", line 929, in run__test__ raise TypeError("Tester.run__test__: values in " TypeError: Tester.run__test__: values in dict must be strings, functions or classes; ****** Does not appear to be specific to Python v2.3. Thanks! Mark ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-16 17:08 Message: Logged In: YES user_id=31435 If it has to be fixed , the only principle I can conjure up is that redundant testing is a waste of time and surprising. On that ground, in the specific example I'd rather skip it, since if the thing had a doctest, it would be most natural to run it from base.myfunc.__doc__. If you're feeling more ambitious, I recently slammed in some useful doctest extensions from Jim Fulton. As I know you've already discovered, there are some warts. The deepest wart isn't obvious: Jim's extensions use their own ways of finding doctests to run. It would be good if everthing used the same ways of finding doctests to run. This bug report shows that doctest's old ways don't always work. It's unknown in how many situations the new ways don't work, and/or deliver different results. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 01:48 Message: Logged In: YES user_id=80475 Tim, would you like me to fix this one by searching the unbound method or by skipping the unbound method? Since classes are searched recursively, it may be reasonable to search the unbound method. However, imports are not searched, so there is a precedent for skipping it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764504&group_id=5470 From noreply@sourceforge.net Wed Jul 16 23:19:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 15:19:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-730467 ] Not detecting AIX_GENUINE_CPLUSPLUS Message-ID: Bugs item #730467, was opened at 2003-04-30 15:22 Message generated for change (Comment added) made by patmiller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730467&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Patrick Miller (patmiller) Assigned to: Nobody/Anonymous (nobody) Summary: Not detecting AIX_GENUINE_CPLUSPLUS Initial Comment: PYthon2.2.2 and Python2.3 AIX xlC Need to update the code in configure.in to remove the hardcoded path for load where we detect AIX_GENUINE_CPLUSPLUS The current version looks for /usr/lpp/xlC/include/load.h but it should just use Without it, Python uses load() for dynamic load instead of loadAndInit() in dynload_aix.c Patch attached # checks for system dependent C++ extensions support case "$ac_sys_system" in AIX*) AC_MSG_CHECKING(for genuine AIX C++ extensions support) AC_TRY_LINK([#include "], [loadAndInit("", 0, "")], [AC_DEFINE(AIX_GENUINE_CPLUSPLUS) AC_MSG_RESULT(yes)], [AC_MSG_RESULT(no)]);; *) ;; esac ---------------------------------------------------------------------- >Comment By: Patrick Miller (patmiller) Date: 2003-07-16 15:19 Message: Logged In: YES user_id=30074 Martin writes: > When you say "update", do you mean that the code was correct The old code was correct because the xlC code was not in the main include directory but rather in the /usr/lpp/xlC directory. IBM apparently moved the file around during various releases of AIX though it settled a few versions ago in /usr/include. Perhaps the proper tactic is to look in the various directories like the perl configuration does: % more ./ext/DynaLoader/hints/aix.pl # See dl_aix.xs for details. use Config; if ($Config{libs} =~ /-lC/ && -f '/lib/libC.a') { $self->{CCFLAGS} = $Config{ccflags} . ' -DUSE_libC'; if (-f '/usr/vacpp/include/load.h') { $self->{CCFLAGS} .= ' -DUSE_vacpp_load_h'; } elsif (-f '/usr/ibmcxx/include/load.h') { $self->{CCFLAGS} .= ' -DUSE_ibmcxx_load_h'; } elsif (-f '/usr/lpp/xlC/include/load.h') { $self->{CCFLAGS} .= ' -DUSE_xlC_load_h'; } elsif (-f '/usr/include/load.h') { $self->{CCFLAGS} .= ' -DUSE_load_h'; } } ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:33 Message: Logged In: YES user_id=21627 When you say "update", do you mean that the code was correct for earlier versions of some software (which versions of which software?), and is now incorrect? With the proposed change, will the new code still run on the old versions of the software? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730467&group_id=5470 From noreply@sourceforge.net Wed Jul 16 23:23:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 15:23:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-730467 ] Not detecting AIX_GENUINE_CPLUSPLUS Message-ID: Bugs item #730467, was opened at 2003-04-30 15:22 Message generated for change (Comment added) made by patmiller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730467&group_id=5470 Category: Build Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Patrick Miller (patmiller) Assigned to: Nobody/Anonymous (nobody) Summary: Not detecting AIX_GENUINE_CPLUSPLUS Initial Comment: PYthon2.2.2 and Python2.3 AIX xlC Need to update the code in configure.in to remove the hardcoded path for load where we detect AIX_GENUINE_CPLUSPLUS The current version looks for /usr/lpp/xlC/include/load.h but it should just use Without it, Python uses load() for dynamic load instead of loadAndInit() in dynload_aix.c Patch attached # checks for system dependent C++ extensions support case "$ac_sys_system" in AIX*) AC_MSG_CHECKING(for genuine AIX C++ extensions support) AC_TRY_LINK([#include "], [loadAndInit("", 0, "")], [AC_DEFINE(AIX_GENUINE_CPLUSPLUS) AC_MSG_RESULT(yes)], [AC_MSG_RESULT(no)]);; *) ;; esac ---------------------------------------------------------------------- >Comment By: Patrick Miller (patmiller) Date: 2003-07-16 15:23 Message: Logged In: YES user_id=30074 Martin also wrote: > will the new code still run on the old versions of I will upload a patch that looks in all the known directories. ---------------------------------------------------------------------- Comment By: Patrick Miller (patmiller) Date: 2003-07-16 15:19 Message: Logged In: YES user_id=30074 Martin writes: > When you say "update", do you mean that the code was correct The old code was correct because the xlC code was not in the main include directory but rather in the /usr/lpp/xlC directory. IBM apparently moved the file around during various releases of AIX though it settled a few versions ago in /usr/include. Perhaps the proper tactic is to look in the various directories like the perl configuration does: % more ./ext/DynaLoader/hints/aix.pl # See dl_aix.xs for details. use Config; if ($Config{libs} =~ /-lC/ && -f '/lib/libC.a') { $self->{CCFLAGS} = $Config{ccflags} . ' -DUSE_libC'; if (-f '/usr/vacpp/include/load.h') { $self->{CCFLAGS} .= ' -DUSE_vacpp_load_h'; } elsif (-f '/usr/ibmcxx/include/load.h') { $self->{CCFLAGS} .= ' -DUSE_ibmcxx_load_h'; } elsif (-f '/usr/lpp/xlC/include/load.h') { $self->{CCFLAGS} .= ' -DUSE_xlC_load_h'; } elsif (-f '/usr/include/load.h') { $self->{CCFLAGS} .= ' -DUSE_load_h'; } } ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:33 Message: Logged In: YES user_id=21627 When you say "update", do you mean that the code was correct for earlier versions of some software (which versions of which software?), and is now incorrect? With the proposed change, will the new code still run on the old versions of the software? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=730467&group_id=5470 From noreply@sourceforge.net Thu Jul 17 00:24:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 16:24:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-762198 ] bug in signal.signal -- raises SystemError Message-ID: Bugs item #762198, was opened at 2003-06-27 17:04 Message generated for change (Comment added) made by robind You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Closed Resolution: None Priority: 1 Submitted By: Jim McCoy (mccoy) Assigned to: Nobody/Anonymous (nobody) Summary: bug in signal.signal -- raises SystemError Initial Comment: Summary pretty much says it all. Using Py2.2.3, win2k (sp4), and twisted 1.0.5 and the call that is triggering the error is as follows: signal.signal(signal.SIGINT, self.sigInt) returns "SystemError: error return without exception set" The twisted gang has tracked it down to a C error of some sort here... ---------------------------------------------------------------------- Comment By: Robin Dunn (robind) Date: 2003-07-16 16:24 Message: Logged In: YES user_id=53955 This fix for this has just been checked in to wxWindows CVS (use WX_2_4_BRANCH tag) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-03 06:06 Message: Logged In: YES user_id=6380 > Generally you get the people that actually work on a package > to fix the package... Right. And since they do it in their spare time, you don't get to tell them what their priorities should be. ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-03 05:47 Message: Logged In: YES user_id=813621 my, my. I do contribute, in fact. Unfortunately, not knowing the many facets of wxWindows is a small (read: large) problem. Generally you get the people that actually work on a package to fix the package... I find it best to follow the 'non-nuked planet scenario' where getting something done doesn't mean learning it all from scratch because no one else exists with the knowledge. Call me crazy... I mean no offense, of course. ;) ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-02 06:12 Message: Logged In: YES user_id=6380 > I'm dying for a resolution on the matter If you really want this resolved, you're going to have to crawl into a debugger and work it yourself. Open Source means you get to contribute, too. :-) ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-02 05:47 Message: Logged In: YES user_id=813621 I already submitted a report on the wxWindows tracker... at the request of a couple of the Twisted guys, I replied to this thread too. I'm dying for a resolution on the matter, so if there's anywhere else I can post this info, please let me know. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-01 10:25 Message: Logged In: YES user_id=6380 OK, there's a clue. Do you know how to report bugs in wxPython? ---------------------------------------------------------------------- Comment By: Phillip Ryals (paryl) Date: 2003-07-01 10:22 Message: Logged In: YES user_id=813621 I can reproduce the problem without importing twisted... Win2k/Python 2.2.2/wxPython 2.4.1.2 >> from signal import * >> signal(SIGINT, lambda *a: None) does not give the error. >> from signal import * >> from wxPython.wx import * >> signal(SIGINT, lambda *a: None) gives the error. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-06-30 09:06 Message: Logged In: YES user_id=6380 I don't have Win2K, but on Win98 I can't reproduce it. The bug report is pretty incomplete -- the call doesn't seem to need Twisted, so what I tried was this: >>> from signal import * >>> signal(SIGINT, lambda *a: None) This returns the previous handler as it should. So please, send more precise data about the problem, or be ignored. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762198&group_id=5470 From noreply@sourceforge.net Thu Jul 17 01:27:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 17:27:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors Message-ID: Bugs item #728330, was opened at 2003-04-27 02:21 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX, 2.3b1, socketmodule.c compilation errors Initial Comment: Python release: 2.3b1 Platform: IRIX 6.5 MIPSpro Compilers: Version 7.3.1.2m Commands used: ./configure --prefix=/usr/local_cci/Python-2.3b1t make The socket module fails to compile. The output from the compiler is attached. ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-16 17:27 Message: Logged In: YES user_id=71407 We have confirmed that the socket module in Python 2.3b1 and 2.3b2 fails to compile under these versions of IRIX: 6.5.10, MIPSpro 7.3.1.2m 6.5.19, MIPSpro 7.3.1.3m 6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge) If Python 2.3 goes out without a working socket module it will be useless for many people in science where IRIX is still found quite frequently. Maybe even worse, we will also no longer be able to advertise Python as a language that "runs everywhere." ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-07-15 15:37 Message: Logged In: YES user_id=71407 Date: Tue, 15 Jul 2003 15:06:25 -0500 From: "Brent Casavant" 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 07:21 Message: Logged In: YES user_id=71407 The socket module still fails to compile with Python 2.3b2, in addition to two other extensions. The full make log is attached. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-21 23:47 Message: Logged In: YES user_id=21627 I think it would be best if detect presence of inet_aton/inet_pton. Is IPv6 support possible on this system? Then it would be best if that was detected, as well. If it is not possible to detect aton/pton/ipv6, what is the problem with not using them? I'd like to have a look at the relevant headers (in particular to understand the duplicate definition of _SGIAPI), indeed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-21 16:35 Message: Logged In: YES user_id=33168 Argh!!! This is a nightmare. The attached hack ^h^h^h patch fixes the problem, but ... _SGIAPI needs to be defined (~192 in socketmodule.c) in order to get the prototypes for inet_aton, inet_pton. But _SGIAPI can't be defined in the standard header files because XOPEN_SOURCE is defined. Martin, do you have any other suggestions? I don't see how to do this right within configure. If you want I can send you the header file(s). ---------------------------------------------------------------------- Comment By: alexandre gillet (gillet) Date: 2003-05-12 10:41 Message: Logged In: YES user_id=150999 I had the same problem compiling socket on Irix. We did find that on our system ENABLE_IPV6 is not define and all the error are cause by that. System that do not enable IPV6 are not well supported with the socketmodule.c code. We were able to compile socket after making few change in the code: I am not sure if I did it right but it compile. I will post my patch but I do not see any place to attach my file example: See line 2794,2800 + #ifdef ENABLE_IPV6 char packed[MAX(sizeof(struct in_addr), sizeof(struct in6_addr))]; + #else + char packed[sizeof(struct in_addr)]; + #endif I am not sure how to post the patch or file. ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2003-05-05 11:44 Message: Logged In: YES user_id=71407 This is not in my area of expertise, but I've tried a couple of (probably stupid) things: #include in socketmodule.c instead of #define _SGIAPI. This resulted in even more errors. ./configure --disable-ipv6 Same errors as before. I am lost here. Sorry. But you still have ssh access to rattler.lbl.gov if that helps. Accounts for other Python developers are a possibility. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-05-04 05:39 Message: Logged In: YES user_id=21627 Can you analyse these compiler errors in more detail, please? What, in your opinion, is causing these problems, and how would you correct them? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 From noreply@sourceforge.net Thu Jul 17 04:20:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 20:20:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-16 21: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=772763&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Nobody/Anonymous (nobody) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Thu Jul 17 04:21:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 20:21:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-16 21:20 Message generated for change (Settings changed) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) >Assigned to: Just van Rossum (jvr) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Thu Jul 17 05:34:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 21:34:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http Message-ID: Bugs item #767111, was opened at 2003-07-07 22:52 Message generated for change (Comment added) made by zenzen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: AttributeError thrown by urllib.open_http Initial Comment: In 2.3b2, looks like an error condition isn't being picked up on line 300 or 301 of urllib.py. The code that triggered this traceback was simply: url = urllib.urlopen(action, data) Traceback (most recent call last): File "autospamrep.py", line 170, in ? current_page = handle_spamcop_page(current_page) File "autospamrep.py", line 140, in handle_spamcop_page url = urllib.urlopen(action, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 78, in urlopen return opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 183, in open return getattr(self, name)(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 308, in open_http return self.http_error(url, fp, errcode, errmsg, headers, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' ---------------------------------------------------------------------- >Comment By: Stuart Bishop (zenzen) Date: 2003-07-17 14:34 Message: Logged In: YES user_id=46639 I've finally managed to get another traceback with some more information, using an assert I inserted into urllib.py a while ago to catch .fp == None: Traceback (most recent call last): File "/Users/zen/bin/autospamrep.py", line 168, in ? current_page = urllib.urlopen(start_url).read() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 76, in urlopen return opener.open(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 181, in open return getattr(self, name)(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 305, in open_http assert fp is not None, 'errcode %r, errmsg %r, headers %r' % (errcode, errmsg, headers) AssertionError: errcode -1, errmsg '', headers None ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-12 23:14 Message: Logged In: YES user_id=261020 HTTPResponse.read returns '' if its .fp is None, but the backwards-compat HTTP class' .getfile() just returns self.file, which it previously grabbed from HTTPResponse in .getreply(). Wild guess: maybe HTTP.getreply should just do self.file = response rather than self.file = response.fp The object returned by HTTP.getfile() was documented as returning an object supporting .readline() and .readlines(), while HTTPResponse only supports .read(), so that's obviously not the whole solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 15:50 Message: Logged In: YES user_id=80475 What were the values of 'action' and 'data' when the call was made? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 From noreply@sourceforge.net Thu Jul 17 05:37:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 21:37:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-772787 ] right button context 'edit with idle' Message-ID: Bugs item #772787, was opened at 2003-07-17 04: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=772787&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: nestor (nestor5) Assigned to: Nobody/Anonymous (nobody) Summary: right button context 'edit with idle' Initial Comment: after installing Python 2.3b2 under windows, the right mouse button context option in windows explorer 'edit with idle' on *.py files ceased to work on two mashines (I upgraded from python b1 to b2). One was Windows 2000 and one was Windows XP. Installation is default C:\python23 installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 From noreply@sourceforge.net Thu Jul 17 07:27:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 23:27:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-764504 ] doctest fails with TypeError Message-ID: Bugs item #764504, was opened at 2003-07-02 05:30 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764504&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open >Resolution: Postponed >Priority: 3 Submitted By: Mark J (average) Assigned to: Raymond Hettinger (rhettinger) Summary: doctest fails with TypeError Initial Comment: #mymod.py: class base(dict): myupdate = dict.update #FINE def myfunc(self): pass class derive(base): myname = base.myfunc #FAILS import doctest, mymod doctest.testmod(mymod) ****** $ python2.3b2 mymod.py Traceback (most recent call last): File "mymod.py", line 8, in ? import doctest, mymod File "/home/me/mymod.py", line 9, in ? doctest.testmod(mymod) File "/usr/local/lib/python2.3/doctest.py", line 1137, in testmod f, t = tester.rundict(m.__dict__, name, m) File "/usr/local/lib/python2.3/doctest.py", line 900, in rundict f2, t2 = self.__runone(value, name + "." + thisname) File "/usr/local/lib/python2.3/doctest.py", line 1061, in __runone return self.rundoc(target, name) File "/usr/local/lib/python2.3/doctest.py", line 820, in rundoc f2, t2 = self.run__test__(d, name) File "/usr/local/lib/python2.3/doctest.py", line 929, in run__test__ raise TypeError("Tester.run__test__: values in " TypeError: Tester.run__test__: values in dict must be strings, functions or classes; ****** Does not appear to be specific to Python v2.3. Thanks! Mark ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-17 01:27 Message: Logged In: YES user_id=80475 Agreed. There is no compelling use case for changing this in Py2.3. Marking as postponed. For Py2.4, there will be plenty of time for merging/improving the underlying search behaviors. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-16 16:08 Message: Logged In: YES user_id=31435 If it has to be fixed , the only principle I can conjure up is that redundant testing is a waste of time and surprising. On that ground, in the specific example I'd rather skip it, since if the thing had a doctest, it would be most natural to run it from base.myfunc.__doc__. If you're feeling more ambitious, I recently slammed in some useful doctest extensions from Jim Fulton. As I know you've already discovered, there are some warts. The deepest wart isn't obvious: Jim's extensions use their own ways of finding doctests to run. It would be good if everthing used the same ways of finding doctests to run. This bug report shows that doctest's old ways don't always work. It's unknown in how many situations the new ways don't work, and/or deliver different results. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 00:48 Message: Logged In: YES user_id=80475 Tim, would you like me to fix this one by searching the unbound method or by skipping the unbound method? Since classes are searched recursively, it may be reasonable to search the unbound method. However, imports are not searched, so there is a precedent for skipping it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764504&group_id=5470 From noreply@sourceforge.net Thu Jul 17 07:28:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 16 Jul 2003 23:28:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-772091 ] doctest.DocTestSuite does not support __test__ Message-ID: Bugs item #772091, was opened at 2003-07-16 00:04 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772091&group_id=5470 Category: Python Library >Group: Python 2.4 Status: Open Resolution: None Priority: 4 Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Raymond Hettinger (rhettinger) Summary: doctest.DocTestSuite does not support __test__ Initial Comment: The DocTestSuite tool ignores a module level dictionary named __test__. This limits its usefulness for the current python testsuite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772091&group_id=5470 From noreply@sourceforge.net Thu Jul 17 11:27:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 03:27:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-772896 ] unknown encoding -> MemoryError Message-ID: Bugs item #772896, was opened at 2003-07-17 19: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=772896&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: unknown encoding -> MemoryError Initial Comment: If you try to install a program and one of the files declares an unknown encoding(like 'UFT-8'), byte-compiling the file fails and get the message, "Sorry: MemoryError: ()" This message obscures the problem and makes it difficult to spot the problem. In fact, it took me a while to find out that the unknown encoding declaration caused the trouble. The error message needs to be more explicit. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772896&group_id=5470 From noreply@sourceforge.net Thu Jul 17 14:42:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 06:42:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors Message-ID: Bugs item #728330, was opened at 2003-04-27 09:21 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX, 2.3b1, socketmodule.c compilation errors 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: Jeremy Hylton (jhylton) Date: 2003-07-17 13: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 00: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 22: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 14: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 06: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 23: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 17: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 18: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 12: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@sourceforge.net Thu Jul 17 14:54:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 06:54:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] IRIX, 2.3b1, socketmodule.c compilation errors Message-ID: Bugs item #728330, was opened at 2003-04-27 09:21 Message generated for change (Comment added) made by jhylton You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: IRIX, 2.3b1, socketmodule.c compilation errors 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: Jeremy Hylton (jhylton) Date: 2003-07-17 13: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 13: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 00: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 22: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 14: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 06: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 23: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 17: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 18: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 12: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@sourceforge.net Thu Jul 17 15:47:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 07:47:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-773020 ] which.py doesn't work on windows Message-ID: Bugs item #773020, was opened at 2003-07-17 16: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=773020&group_id=5470 Category: Demos and Tools Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Shasckaw Lionfaith (shasckaw) Assigned to: Nobody/Anonymous (nobody) Summary: which.py doesn't work on windows Initial Comment: which.py can't find any given file in the paths given in PATH variable. To debug this, should replace the line: pathlist = string.splitfields(os.environ['PATH'], ':') by this line: pathlist = string.splitfields(os.environ['PATH'], os.pathsep) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773020&group_id=5470 From noreply@sourceforge.net Thu Jul 17 17:20:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 09:20:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-767645 ] incorrect os.path.supports_unicode_filenames Message-ID: Bugs item #767645, was opened at 2003-07-08 11:42 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Open >Resolution: Later Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect os.path.supports_unicode_filenames Initial Comment: At least on OSX, unicode file names are pretty much fully supported, yet os.path.supports_unicode_filenames is False (it comes from posixpath.py, which hard codes it). What would be a proper way to detect unicode filename support for posix platforms? ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:20 Message: Logged In: YES user_id=92689 Reopeing as the fix I checked in caused problems in test_pep277.py. Postpone work on this until after 2.3 is released. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-11 09:48 Message: Logged In: YES user_id=92689 Done in rev. 1.61 of posixpath.py. (Actually, OSX does complain when you feed open() a non-valid utf-8 string (albeit with a misleading error message). The OS also makes sure the name is converted to its preferred form, eg. if I create a file named u'\xc7', I can also open it as u'C\u0327', and os.listdir() will always show the latter, no matter how you created the file.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-11 00:34 Message: Logged In: YES user_id=21627 >I'm not 100% sure, but I think the OS corrects that I'm relatively sure that the OS doesn't. The OS won't complain if you pass a file name that isn't UTF-8 at all - Finder will then fail to display the file correctly. There are CoreFoundationsBasicServicesSomething functions that you are supposed to call to correct that; Python does not use them. If you think setting the flag for darwin is fine in posixpath, just go ahead. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-10 23:13 Message: Logged In: YES user_id=92689 > On OSX, the situation is somewhat different from POSIX, as > you have additional functions to open files (which Python > apparently does not use, though), and because OSX specifies > that the byte strings have to be NFD UTF-8 (which Python > violates AFAICT). (I'm not 100% sure, but I think the OS corrects that) > True if arbitrary Unicode strings can be used as file names > (within limitations imposed by the file system), and if > \function{os.listdir()} returns Unicode strings for a Unicode > argument. > > While the first part is true for OSX, I don't think the > second part is. It is, we had a long discussion about that back when I implemented that ;-) > If that ever gets corrected (or verified), > no further detection is necessary - just set > macpath.supports_unicode_filenames for darwin (assuming you > use macpath.py on that system). Darwin is a posix platform, so I'll have to add a switch to posixpath.py. Unless you object to that, I will do that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:05 Message: Logged In: YES user_id=21627 Brett: As for "writing Unicode to an ASCII file system": there is no such thing. POSIX file systems accept arbitrary bytes, and don't interpret them except by looking at the path separator (in ASCII). So you can put Latin-1, KOI8-r, EUC-JP, UTF-8, gb2312, etc all on a single file system, and people actually do that. The convention is that bytes in file names are interpreted according to the locale's encoding. This is just a convention, and it has some significant flaws. Python follows that convention, meaning that you can use arbitrary Unicode strings in open(), as long as they are supported in the locale's encoding. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:01 Message: Logged In: YES user_id=21627 On POSIX platforms in general, detecting Unicode file name support is not possible. Posix uses open(2), and only open(2) (alon with creat(2), stat(2) etc) to access files. There is no open_w, or open_utf8, or the like. So file names are byte strings on Posix, and it will stay that way forever. (There is actually also fopen, but that doesn't change the situation at all). On OSX, the situation is somewhat different from POSIX, as you have additional functions to open files (which Python apparently does not use, though), and because OSX specifies that the byte strings have to be NFD UTF-8 (which Python violates AFAICT). The documentation for supports_unicode_filenames says True if arbitrary Unicode strings can be used as file names (within limitations imposed by the file system), and if \function{os.listdir()} returns Unicode strings for a Unicode argument. While the first part is true for OSX, I don't think the second part is. If that ever gets corrected (or verified), no further detection is necessary - just set macpath.supports_unicode_filenames for darwin (assuming you use macpath.py on that system). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 20:07 Message: Logged In: YES user_id=357491 What happens if you try to create a file using Unicode names? Could a test get the temp directory for the platform, write a file with Unicode in it, and then check for an error? Or if it always succeeds, write it, and then see if the results match? In other words, does writing Unicode to an ASCII file system ever lead to a mangling of the name? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 From noreply@sourceforge.net Thu Jul 17 17:21:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 09:21:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-767645 ] incorrect os.path.supports_unicode_filenames Message-ID: Bugs item #767645, was opened at 2003-07-08 11:42 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: Later Priority: 5 Submitted By: Just van Rossum (jvr) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect os.path.supports_unicode_filenames Initial Comment: At least on OSX, unicode file names are pretty much fully supported, yet os.path.supports_unicode_filenames is False (it comes from posixpath.py, which hard codes it). What would be a proper way to detect unicode filename support for posix platforms? ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:21 Message: Logged In: YES user_id=92689 (forgot to mention: my checkin was backed out) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:20 Message: Logged In: YES user_id=92689 Reopeing as the fix I checked in caused problems in test_pep277.py. Postpone work on this until after 2.3 is released. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-11 09:48 Message: Logged In: YES user_id=92689 Done in rev. 1.61 of posixpath.py. (Actually, OSX does complain when you feed open() a non-valid utf-8 string (albeit with a misleading error message). The OS also makes sure the name is converted to its preferred form, eg. if I create a file named u'\xc7', I can also open it as u'C\u0327', and os.listdir() will always show the latter, no matter how you created the file.) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-11 00:34 Message: Logged In: YES user_id=21627 >I'm not 100% sure, but I think the OS corrects that I'm relatively sure that the OS doesn't. The OS won't complain if you pass a file name that isn't UTF-8 at all - Finder will then fail to display the file correctly. There are CoreFoundationsBasicServicesSomething functions that you are supposed to call to correct that; Python does not use them. If you think setting the flag for darwin is fine in posixpath, just go ahead. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-10 23:13 Message: Logged In: YES user_id=92689 > On OSX, the situation is somewhat different from POSIX, as > you have additional functions to open files (which Python > apparently does not use, though), and because OSX specifies > that the byte strings have to be NFD UTF-8 (which Python > violates AFAICT). (I'm not 100% sure, but I think the OS corrects that) > True if arbitrary Unicode strings can be used as file names > (within limitations imposed by the file system), and if > \function{os.listdir()} returns Unicode strings for a Unicode > argument. > > While the first part is true for OSX, I don't think the > second part is. It is, we had a long discussion about that back when I implemented that ;-) > If that ever gets corrected (or verified), > no further detection is necessary - just set > macpath.supports_unicode_filenames for darwin (assuming you > use macpath.py on that system). Darwin is a posix platform, so I'll have to add a switch to posixpath.py. Unless you object to that, I will do that. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:05 Message: Logged In: YES user_id=21627 Brett: As for "writing Unicode to an ASCII file system": there is no such thing. POSIX file systems accept arbitrary bytes, and don't interpret them except by looking at the path separator (in ASCII). So you can put Latin-1, KOI8-r, EUC-JP, UTF-8, gb2312, etc all on a single file system, and people actually do that. The convention is that bytes in file names are interpreted according to the locale's encoding. This is just a convention, and it has some significant flaws. Python follows that convention, meaning that you can use arbitrary Unicode strings in open(), as long as they are supported in the locale's encoding. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-10 23:01 Message: Logged In: YES user_id=21627 On POSIX platforms in general, detecting Unicode file name support is not possible. Posix uses open(2), and only open(2) (alon with creat(2), stat(2) etc) to access files. There is no open_w, or open_utf8, or the like. So file names are byte strings on Posix, and it will stay that way forever. (There is actually also fopen, but that doesn't change the situation at all). On OSX, the situation is somewhat different from POSIX, as you have additional functions to open files (which Python apparently does not use, though), and because OSX specifies that the byte strings have to be NFD UTF-8 (which Python violates AFAICT). The documentation for supports_unicode_filenames says True if arbitrary Unicode strings can be used as file names (within limitations imposed by the file system), and if \function{os.listdir()} returns Unicode strings for a Unicode argument. While the first part is true for OSX, I don't think the second part is. If that ever gets corrected (or verified), no further detection is necessary - just set macpath.supports_unicode_filenames for darwin (assuming you use macpath.py on that system). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 20:07 Message: Logged In: YES user_id=357491 What happens if you try to create a file using Unicode names? Could a test get the temp directory for the platform, write a file with Unicode in it, and then check for an error? Or if it always succeeds, write it, and then see if the results match? In other words, does writing Unicode to an ASCII file system ever lead to a mangling of the name? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767645&group_id=5470 From noreply@sourceforge.net Thu Jul 17 17:22:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 09:22:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-17 05:20 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Just van Rossum (jvr) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:22 Message: Logged In: YES user_id=92689 This should be done with the "U" mode indeed. Can you provide a patch? It's too late for 2.3 anyway, so take your time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Thu Jul 17 17:27:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 09:27:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-16 21:20 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Just van Rossum (jvr) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 10:27 Message: Logged In: YES user_id=619560 The only problem is that the file is opened within the imp module when the find_module() method. So this means changes at the C level, right? And its already too late for Python 2.3?? I thought it was still two weeks away from release? Perhaps the simple fix with the replace() code can be used for now? I am not sure about the release strategy so I might be way off base here. :-) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 10:22 Message: Logged In: YES user_id=92689 This should be done with the "U" mode indeed. Can you provide a patch? It's too late for 2.3 anyway, so take your time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Thu Jul 17 17:29:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 09:29:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-17 05:20 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Just van Rossum (jvr) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:29 Message: Logged In: YES user_id=92689 Ah, imp :-(. 2.3: they're baking the release candidate today, so yeah, it's too late :-( ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 18:27 Message: Logged In: YES user_id=619560 The only problem is that the file is opened within the imp module when the find_module() method. So this means changes at the C level, right? And its already too late for Python 2.3?? I thought it was still two weeks away from release? Perhaps the simple fix with the replace() code can be used for now? I am not sure about the release strategy so I might be way off base here. :-) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:22 Message: Logged In: YES user_id=92689 This should be done with the "U" mode indeed. Can you provide a patch? It's too late for 2.3 anyway, so take your time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Thu Jul 17 17:46:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 09:46:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-773020 ] which.py doesn't work on windows Message-ID: Bugs item #773020, was opened at 2003-07-17 09:47 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773020&group_id=5470 Category: Demos and Tools Group: Python 2.2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Shasckaw Lionfaith (shasckaw) >Assigned to: Skip Montanaro (montanaro) Summary: which.py doesn't work on windows Initial Comment: which.py can't find any given file in the paths given in PATH variable. To debug this, should replace the line: pathlist = string.splitfields(os.environ['PATH'], ':') by this line: pathlist = string.splitfields(os.environ['PATH'], os.pathsep) ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-17 11:46 Message: Logged In: YES user_id=44345 fixed thanks. which.py 1.12 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773020&group_id=5470 From noreply@sourceforge.net Thu Jul 17 17:57:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 09:57:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-17 05:20 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Just van Rossum (jvr) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-07-17 18:57 Message: Logged In: YES user_id=11105 Per the comment at the top of the file, modulefinder should be kept compatible with 1.5.2, so the "U" mode should be used with care ;-) OTOH, *I* requested the compatibility, and I no longer see a need for it. Should the compat request be removed? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:29 Message: Logged In: YES user_id=92689 Ah, imp :-(. 2.3: they're baking the release candidate today, so yeah, it's too late :-( ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 18:27 Message: Logged In: YES user_id=619560 The only problem is that the file is opened within the imp module when the find_module() method. So this means changes at the C level, right? And its already too late for Python 2.3?? I thought it was still two weeks away from release? Perhaps the simple fix with the replace() code can be used for now? I am not sure about the release strategy so I might be way off base here. :-) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:22 Message: Logged In: YES user_id=92689 This should be done with the "U" mode indeed. Can you provide a patch? It's too late for 2.3 anyway, so take your time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Thu Jul 17 18:09:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 10:09:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-16 21:20 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Just van Rossum (jvr) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 11:09 Message: Logged In: YES user_id=619560 It is already incompatible since the removal of apply() took place a while back. I would not mind seeing the compat request removed. It removes constraints from future development. OTOH, the "U" stuff would have to be added to the imp module when it opens the file. Thus, the modulefinder.py file itself would not change. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-07-17 10:57 Message: Logged In: YES user_id=11105 Per the comment at the top of the file, modulefinder should be kept compatible with 1.5.2, so the "U" mode should be used with care ;-) OTOH, *I* requested the compatibility, and I no longer see a need for it. Should the compat request be removed? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 10:29 Message: Logged In: YES user_id=92689 Ah, imp :-(. 2.3: they're baking the release candidate today, so yeah, it's too late :-( ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 10:27 Message: Logged In: YES user_id=619560 The only problem is that the file is opened within the imp module when the find_module() method. So this means changes at the C level, right? And its already too late for Python 2.3?? I thought it was still two weeks away from release? Perhaps the simple fix with the replace() code can be used for now? I am not sure about the release strategy so I might be way off base here. :-) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 10:22 Message: Logged In: YES user_id=92689 This should be done with the "U" mode indeed. Can you provide a patch? It's too late for 2.3 anyway, so take your time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Thu Jul 17 19:07:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 11:07:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-728330 ] Don't define _SGAPI on IRIX Message-ID: Bugs item #728330, was opened at 2003-04-27 09:21 Message generated for change (Comment added) made by jhylton 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: Nobody/Anonymous (nobody) >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: Jeremy Hylton (jhylton) Date: 2003-07-17 18: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 13: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 13: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 00: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 22: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 14: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 06: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 23: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 17: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 18: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 12: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@sourceforge.net Thu Jul 17 22:36:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 14:36:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-773286 ] nconsistant results for os.listdir,os.path.isdir on W2k Message-ID: Bugs item #773286, was opened at 2003-07-17 14: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=773286&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard F. Emerson (remerson) Assigned to: Nobody/Anonymous (nobody) Summary: nconsistant results for os.listdir,os.path.isdir on W2k Initial Comment: Inconsistant results when using os.listdir,os.path.isdir and os.path.isfile on the win200 platform. Run the following script and compare with a directroy view. They do not match for the second directory of the two. """ to separate the sub directories from the files in a directory""" import os p1=os.getcwd() x=os.listdir(p1) p2= os.path.join("c:\","python~1","Tools") y=os.listdir(p2) #cwd = os.path.join("c:\") #cwd=cwd+"\doc\" #cwd="c:\python~1\Doc" #cwd=cwd+"\Qualcomm"+"\Eduora" #print x,y print "path",p1,"\n" print "directories","\n" for item in x: #print item if os.path.isdir(item): print " ",item print "\n","files","\n" for item in os.listdir(cwd): if os.path.isfile(item): print " ",item print "path",p2,"\n" print "directories","\n" for item in y: #print item if os.path.isdir(item): print " ",item print "\n","files","\n" for item in os.listdir(cwd): if os.path.isfile(item): print " ",item the lists x and y do contain all the file and directory names and one would expect the same sorting of both lists into directories only and files only. Not so on my machine. Results path C:\PYTHON~1 directories DLLs Doc include Lib libs Qualcomm tcl Tools files Circle.py Circle.pyc INSTALL.LOG LICENSE.txt log.bak Log.py Log.pyc mailspin.py mailspin.pyc mailspin1.py NEWS.txt py.ico pyc.ico pycon.ico python.exe pythonw.exe README.txt Requirements for the Message Separator.doc session.txt test dirs.py test dirs1.py test file.txt w9xpopen.exe path c:\python~1\Tools directories files Circle.py Circle.pyc INSTALL.LOG LICENSE.txt log.bak Log.py Log.pyc mailspin.py mailspin.pyc mailspin1.py NEWS.txt py.ico pyc.ico pycon.ico python.exe pythonw.exe README.txt Requirements for the Message Separator.doc session.txt test dirs.py test dirs1.py test file.txt w9xpopen.exe The tools sub directory is as delivered with the distribution. The Python~1 directory has had a few files added. Though I am new to Python, I tried locating the functions or classes that implemented the dirlist, isdir and isfile with only limited success. I looked in os, os.path and ntpath. I can be reached by phone at 818.354.3848 if more immediate communications is required to understand the problem (mine or the library's ) and resolve it. Regards Dick ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773286&group_id=5470 From noreply@sourceforge.net Thu Jul 17 23:24:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 15:24:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-16 21:20 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Just van Rossum (jvr) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 16:24 Message: Logged In: YES user_id=619560 As it turns out, import.c has already been modified to handle universal line endings so this is not a bug for Python 2.3. It is rather a bug for Python 2.2 and lower. So I guess we should decide whether or not to remove the requirement for Python 1.5 support sooner rather than later. I can modify my own copy for Python 2.2 to handle this situation properly. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 11:09 Message: Logged In: YES user_id=619560 It is already incompatible since the removal of apply() took place a while back. I would not mind seeing the compat request removed. It removes constraints from future development. OTOH, the "U" stuff would have to be added to the imp module when it opens the file. Thus, the modulefinder.py file itself would not change. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-07-17 10:57 Message: Logged In: YES user_id=11105 Per the comment at the top of the file, modulefinder should be kept compatible with 1.5.2, so the "U" mode should be used with care ;-) OTOH, *I* requested the compatibility, and I no longer see a need for it. Should the compat request be removed? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 10:29 Message: Logged In: YES user_id=92689 Ah, imp :-(. 2.3: they're baking the release candidate today, so yeah, it's too late :-( ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 10:27 Message: Logged In: YES user_id=619560 The only problem is that the file is opened within the imp module when the find_module() method. So this means changes at the C level, right? And its already too late for Python 2.3?? I thought it was still two weeks away from release? Perhaps the simple fix with the replace() code can be used for now? I am not sure about the release strategy so I might be way off base here. :-) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 10:22 Message: Logged In: YES user_id=92689 This should be done with the "U" mode indeed. Can you provide a patch? It's too late for 2.3 anyway, so take your time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Fri Jul 18 01:10:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 17:10:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-773351 ] Dubious use of Unicode literals in tutorial Message-ID: Bugs item #773351, was opened at 2003-07-18 02: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=773351&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Martin v. Löwis (loewis) Summary: Dubious use of Unicode literals in tutorial Initial Comment: "3.1.3 Unicode Strings" contains: >>> u"äöü" u'\xe4\xf6\xfc' It looks like latin1 is used as encoding for this Unicode literal. This is, however, neither justified by the Python language specification nor by common sense ;-) I'd suggest that this be changed in the tutorial. Furthermore I'd suggest that such use of Unicode literals throw errors instead. I'm assigning it to Martin, because he's one of the Unicode gurus :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773351&group_id=5470 From noreply@sourceforge.net Fri Jul 18 01:24:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 17:24:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-773356 ] posix needs to generate unicode filenames where necessary Message-ID: Bugs item #773356, was opened at 2003-07-17 19:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773356&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: posix needs to generate unicode filenames where necessary Initial Comment: Mac OS X supports Unicode filenames. At the moment this can't be enabled because when raising an IOError the filename embedded in the IOError exception (and perhaps others) is a plain string. This attribute should be a unicode object where necessary. This can be demonstrated by building on Mac OS X with the last line of posixpath.py replaced with if sys.platform == "darwin": supports_unicode_filenames = True else: supports_unicode_filenames = False and running the interpreter against Lib/test/test_pep277.py. This needs to be corrected after the 2.3 release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773356&group_id=5470 From noreply@sourceforge.net Fri Jul 18 03:11:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 19:11:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-773286 ] nconsistant results for os.listdir,os.path.isdir on W2k Message-ID: Bugs item #773286, was opened at 2003-07-17 16:36 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773286&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard F. Emerson (remerson) Assigned to: Nobody/Anonymous (nobody) Summary: nconsistant results for os.listdir,os.path.isdir on W2k Initial Comment: Inconsistant results when using os.listdir,os.path.isdir and os.path.isfile on the win200 platform. Run the following script and compare with a directroy view. They do not match for the second directory of the two. """ to separate the sub directories from the files in a directory""" import os p1=os.getcwd() x=os.listdir(p1) p2= os.path.join("c:\","python~1","Tools") y=os.listdir(p2) #cwd = os.path.join("c:\") #cwd=cwd+"\doc\" #cwd="c:\python~1\Doc" #cwd=cwd+"\Qualcomm"+"\Eduora" #print x,y print "path",p1,"\n" print "directories","\n" for item in x: #print item if os.path.isdir(item): print " ",item print "\n","files","\n" for item in os.listdir(cwd): if os.path.isfile(item): print " ",item print "path",p2,"\n" print "directories","\n" for item in y: #print item if os.path.isdir(item): print " ",item print "\n","files","\n" for item in os.listdir(cwd): if os.path.isfile(item): print " ",item the lists x and y do contain all the file and directory names and one would expect the same sorting of both lists into directories only and files only. Not so on my machine. Results path C:\PYTHON~1 directories DLLs Doc include Lib libs Qualcomm tcl Tools files Circle.py Circle.pyc INSTALL.LOG LICENSE.txt log.bak Log.py Log.pyc mailspin.py mailspin.pyc mailspin1.py NEWS.txt py.ico pyc.ico pycon.ico python.exe pythonw.exe README.txt Requirements for the Message Separator.doc session.txt test dirs.py test dirs1.py test file.txt w9xpopen.exe path c:\python~1\Tools directories files Circle.py Circle.pyc INSTALL.LOG LICENSE.txt log.bak Log.py Log.pyc mailspin.py mailspin.pyc mailspin1.py NEWS.txt py.ico pyc.ico pycon.ico python.exe pythonw.exe README.txt Requirements for the Message Separator.doc session.txt test dirs.py test dirs1.py test file.txt w9xpopen.exe The tools sub directory is as delivered with the distribution. The Python~1 directory has had a few files added. Though I am new to Python, I tried locating the functions or classes that implemented the dirlist, isdir and isfile with only limited success. I looked in os, os.path and ntpath. I can be reached by phone at 818.354.3848 if more immediate communications is required to understand the problem (mine or the library's ) and resolve it. Regards Dick ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-17 21:11 Message: Logged In: YES user_id=80475 What is the issue? * Is it a matter of os.listdir() having a sort order different from that shown by another windows tool? If so, then that is not a bug (the sort order is not guaranteed by the underlying o.s.). * Is there another tool that makes different idenfications of what is a directory vs what is a file? If so, please include a DOS listing of the file attributes ("attrib *.*") and a similar list from Python: for filename is os.listdir(p): print filename, os.isdir(filename), os.isfile(filename) * Is there any internal inconsistency within Python. If so, please show the comparative result. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773286&group_id=5470 From noreply@sourceforge.net Fri Jul 18 06:59:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 22:59:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-773450 ] 2.3b2 pimp.py calls non-existent routine Message-ID: Bugs item #773450, was opened at 2003-07-17 22: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=773450&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Jack Jansen (jackjansen) Summary: 2.3b2 pimp.py calls non-existent routine Initial Comment: On line 589, there is a call to _fmtpackagename(self). No such routine is there, nor is there anything in the distribution that contains the string packagename, in any case, that looks suitable. This is in the 2.3b2 distribution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773450&group_id=5470 From noreply@sourceforge.net Fri Jul 18 07:43:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 17 Jul 2003 23:43:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-17 05:20 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Just van Rossum (jvr) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-07-18 08:43 Message: Logged In: YES user_id=11105 FYI, I've filed patch 773179, which changes the compatibility requirements for modulefinder to >= Python 2.2. I don't want py2exe to support older versions anymore. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-18 00:24 Message: Logged In: YES user_id=619560 As it turns out, import.c has already been modified to handle universal line endings so this is not a bug for Python 2.3. It is rather a bug for Python 2.2 and lower. So I guess we should decide whether or not to remove the requirement for Python 1.5 support sooner rather than later. I can modify my own copy for Python 2.2 to handle this situation properly. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 19:09 Message: Logged In: YES user_id=619560 It is already incompatible since the removal of apply() took place a while back. I would not mind seeing the compat request removed. It removes constraints from future development. OTOH, the "U" stuff would have to be added to the imp module when it opens the file. Thus, the modulefinder.py file itself would not change. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-07-17 18:57 Message: Logged In: YES user_id=11105 Per the comment at the top of the file, modulefinder should be kept compatible with 1.5.2, so the "U" mode should be used with care ;-) OTOH, *I* requested the compatibility, and I no longer see a need for it. Should the compat request be removed? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:29 Message: Logged In: YES user_id=92689 Ah, imp :-(. 2.3: they're baking the release candidate today, so yeah, it's too late :-( ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 18:27 Message: Logged In: YES user_id=619560 The only problem is that the file is opened within the imp module when the find_module() method. So this means changes at the C level, right? And its already too late for Python 2.3?? I thought it was still two weeks away from release? Perhaps the simple fix with the replace() code can be used for now? I am not sure about the release strategy so I might be way off base here. :-) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:22 Message: Logged In: YES user_id=92689 This should be done with the "U" mode indeed. Can you provide a patch? It's too late for 2.3 anyway, so take your time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Fri Jul 18 08:52:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 00:52:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-773476 ] import site fails in certain embedding situations Message-ID: Bugs item #773476, was opened at 2003-07-18 17:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 8 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: import site fails in certain embedding situations Initial Comment: In certain situations (python23.dll and python23.zip in the same dir, no PYTHON related env vars set, no Python registry values), Python will fail to import site. Exception is: import site # loaded from Zip C:\build\mozilla\dist\bin\python23.zip\site.pyo 'import site' failed; traceback: Traceback (most recent call last): File ".\site.py", line 191, in ? NameError: name 'sitedir' is not defined This exception is the result of there being no "prefixes", so sitedir is never bound to a value. This, the del of sitedir fails. Suggested patch is attached (just setting sitedir to None before the loop) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 From noreply@sourceforge.net Fri Jul 18 09:06:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 01:06:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-773476 ] import site fails in certain embedding situations Message-ID: Bugs item #773476, was opened at 2003-07-18 02:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 Category: None Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 8 Submitted By: Mark Hammond (mhammond) >Assigned to: Mark Hammond (mhammond) Summary: import site fails in certain embedding situations Initial Comment: In certain situations (python23.dll and python23.zip in the same dir, no PYTHON related env vars set, no Python registry values), Python will fail to import site. Exception is: import site # loaded from Zip C:\build\mozilla\dist\bin\python23.zip\site.pyo 'import site' failed; traceback: Traceback (most recent call last): File ".\site.py", line 191, in ? NameError: name 'sitedir' is not defined This exception is the result of there being no "prefixes", so sitedir is never bound to a value. This, the del of sitedir fails. Suggested patch is attached (just setting sitedir to None before the loop) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-18 03:06 Message: Logged In: YES user_id=80475 "sitedir = []" would be a better choice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 From noreply@sourceforge.net Fri Jul 18 10:54:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 02:54:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-773351 ] Dubious use of Unicode literals in tutorial Message-ID: Bugs item #773351, was opened at 2003-07-18 02:10 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773351&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None >Priority: 1 Submitted By: Gerhard Häring (ghaering) Assigned to: Martin v. Löwis (loewis) Summary: Dubious use of Unicode literals in tutorial Initial Comment: "3.1.3 Unicode Strings" contains: >>> u"äöü" u'\xe4\xf6\xfc' It looks like latin1 is used as encoding for this Unicode literal. This is, however, neither justified by the Python language specification nor by common sense ;-) I'd suggest that this be changed in the tutorial. Furthermore I'd suggest that such use of Unicode literals throw errors instead. I'm assigning it to Martin, because he's one of the Unicode gurus :) ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2003-07-18 11:54 Message: Logged In: YES user_id=163326 I *do* get the warnings when executing scripts, but I do *not* get the warnings at the interactive prompt. Lowering priority accordingly. Feel free to close this if this is indeed the intended behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773351&group_id=5470 From noreply@sourceforge.net Fri Jul 18 10:55:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 02:55:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-773351 ] Dubious use of Unicode literals in tutorial Message-ID: Bugs item #773351, was opened at 2003-07-18 02:10 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773351&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None >Priority: 5 Submitted By: Gerhard Häring (ghaering) >Assigned to: Gerhard Häring (ghaering) Summary: Dubious use of Unicode literals in tutorial Initial Comment: "3.1.3 Unicode Strings" contains: >>> u"äöü" u'\xe4\xf6\xfc' It looks like latin1 is used as encoding for this Unicode literal. This is, however, neither justified by the Python language specification nor by common sense ;-) I'd suggest that this be changed in the tutorial. Furthermore I'd suggest that such use of Unicode literals throw errors instead. I'm assigning it to Martin, because he's one of the Unicode gurus :) ---------------------------------------------------------------------- >Comment By: Gerhard Häring (ghaering) Date: 2003-07-18 11:55 Message: Logged In: YES user_id=163326 Oh, I almost forgot about my original problem. Such behaviour shouldn't be encouraged in the tutorial any longer of course. Maybe I can find a better wording and submit a patch soonish. Now that I understand this better, assignnig this to myself :) ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2003-07-18 11:54 Message: Logged In: YES user_id=163326 I *do* get the warnings when executing scripts, but I do *not* get the warnings at the interactive prompt. Lowering priority accordingly. Feel free to close this if this is indeed the intended behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773351&group_id=5470 From noreply@sourceforge.net Fri Jul 18 14:29:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 06:29:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-773476 ] import site fails in certain embedding situations Message-ID: Bugs item #773476, was opened at 2003-07-18 17:52 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: Accepted Priority: 8 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: import site fails in certain embedding situations Initial Comment: In certain situations (python23.dll and python23.zip in the same dir, no PYTHON related env vars set, no Python registry values), Python will fail to import site. Exception is: import site # loaded from Zip C:\build\mozilla\dist\bin\python23.zip\site.pyo 'import site' failed; traceback: Traceback (most recent call last): File ".\site.py", line 191, in ? NameError: name 'sitedir' is not defined This exception is the result of there being no "prefixes", so sitedir is never bound to a value. This, the del of sitedir fails. Suggested patch is attached (just setting sitedir to None before the loop) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-07-18 23:29 Message: Logged In: YES user_id=14198 The exception is "sitedir" - but I do concede a better patch would involve sitedirs=[]; sitedir=None and zapping both. However, as site is executed as a standard module, the cleanup of the namespace seems a little anal - especially now we have __all__ - so maybe deleting the dels would be better still But given we are so close to release, and that the 'noun' in the exception is singular, I still prefer None (but I would be happy to settle for sitedir="winK" #wink) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-18 18:06 Message: Logged In: YES user_id=80475 "sitedir = []" would be a better choice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 From noreply@sourceforge.net Fri Jul 18 14:30:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 06:30:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-773476 ] import site fails in certain embedding situations Message-ID: Bugs item #773476, was opened at 2003-07-18 17:52 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 >Category: Windows Group: Python 2.3 Status: Open Resolution: Accepted Priority: 8 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: import site fails in certain embedding situations Initial Comment: In certain situations (python23.dll and python23.zip in the same dir, no PYTHON related env vars set, no Python registry values), Python will fail to import site. Exception is: import site # loaded from Zip C:\build\mozilla\dist\bin\python23.zip\site.pyo 'import site' failed; traceback: Traceback (most recent call last): File ".\site.py", line 191, in ? NameError: name 'sitedir' is not defined This exception is the result of there being no "prefixes", so sitedir is never bound to a value. This, the del of sitedir fails. Suggested patch is attached (just setting sitedir to None before the loop) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-18 23:29 Message: Logged In: YES user_id=14198 The exception is "sitedir" - but I do concede a better patch would involve sitedirs=[]; sitedir=None and zapping both. However, as site is executed as a standard module, the cleanup of the namespace seems a little anal - especially now we have __all__ - so maybe deleting the dels would be better still But given we are so close to release, and that the 'noun' in the exception is singular, I still prefer None (but I would be happy to settle for sitedir="winK" #wink) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-18 18:06 Message: Logged In: YES user_id=80475 "sitedir = []" would be a better choice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 From noreply@sourceforge.net Fri Jul 18 14:37:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 06:37:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-16 21:20 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Just van Rossum (jvr) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2003-07-18 07:37 Message: Logged In: YES user_id=619560 If that is the case, there is still a bug for usage in 2.2. Then you must make the changes as noted above or you will run into problems with DOS line endings on a Unix platform. Whether or not this must be fixed in the main library or whether those of us who bundle the code need to make the changes ourselves is up to those who manage Python. I am no longer concerned since it does work with Python 2.3. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-07-18 00:43 Message: Logged In: YES user_id=11105 FYI, I've filed patch 773179, which changes the compatibility requirements for modulefinder to >= Python 2.2. I don't want py2exe to support older versions anymore. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 16:24 Message: Logged In: YES user_id=619560 As it turns out, import.c has already been modified to handle universal line endings so this is not a bug for Python 2.3. It is rather a bug for Python 2.2 and lower. So I guess we should decide whether or not to remove the requirement for Python 1.5 support sooner rather than later. I can modify my own copy for Python 2.2 to handle this situation properly. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 11:09 Message: Logged In: YES user_id=619560 It is already incompatible since the removal of apply() took place a while back. I would not mind seeing the compat request removed. It removes constraints from future development. OTOH, the "U" stuff would have to be added to the imp module when it opens the file. Thus, the modulefinder.py file itself would not change. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-07-17 10:57 Message: Logged In: YES user_id=11105 Per the comment at the top of the file, modulefinder should be kept compatible with 1.5.2, so the "U" mode should be used with care ;-) OTOH, *I* requested the compatibility, and I no longer see a need for it. Should the compat request be removed? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 10:29 Message: Logged In: YES user_id=92689 Ah, imp :-(. 2.3: they're baking the release candidate today, so yeah, it's too late :-( ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 10:27 Message: Logged In: YES user_id=619560 The only problem is that the file is opened within the imp module when the find_module() method. So this means changes at the C level, right? And its already too late for Python 2.3?? I thought it was still two weeks away from release? Perhaps the simple fix with the replace() code can be used for now? I am not sure about the release strategy so I might be way off base here. :-) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 10:22 Message: Logged In: YES user_id=92689 This should be done with the "U" mode indeed. Can you provide a patch? It's too late for 2.3 anyway, so take your time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Fri Jul 18 14:45:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 06:45:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-773476 ] import site fails in certain embedding situations Message-ID: Bugs item #773476, was opened at 2003-07-18 02:52 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: Accepted Priority: 8 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: import site fails in certain embedding situations Initial Comment: In certain situations (python23.dll and python23.zip in the same dir, no PYTHON related env vars set, no Python registry values), Python will fail to import site. Exception is: import site # loaded from Zip C:\build\mozilla\dist\bin\python23.zip\site.pyo 'import site' failed; traceback: Traceback (most recent call last): File ".\site.py", line 191, in ? NameError: name 'sitedir' is not defined This exception is the result of there being no "prefixes", so sitedir is never bound to a value. This, the del of sitedir fails. Suggested patch is attached (just setting sitedir to None before the loop) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-18 08:45 Message: Logged In: YES user_id=80475 Then None it is. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-18 08:29 Message: Logged In: YES user_id=14198 The exception is "sitedir" - but I do concede a better patch would involve sitedirs=[]; sitedir=None and zapping both. However, as site is executed as a standard module, the cleanup of the namespace seems a little anal - especially now we have __all__ - so maybe deleting the dels would be better still But given we are so close to release, and that the 'noun' in the exception is singular, I still prefer None (but I would be happy to settle for sitedir="winK" #wink) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-18 03:06 Message: Logged In: YES user_id=80475 "sitedir = []" would be a better choice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 From noreply@sourceforge.net Fri Jul 18 16:04:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 08:04:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-773351 ] Dubious use of Unicode literals in tutorial Message-ID: Bugs item #773351, was opened at 2003-07-18 02:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773351&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gerhard Häring (ghaering) Assigned to: Gerhard Häring (ghaering) Summary: Dubious use of Unicode literals in tutorial Initial Comment: "3.1.3 Unicode Strings" contains: >>> u"äöü" u'\xe4\xf6\xfc' It looks like latin1 is used as encoding for this Unicode literal. This is, however, neither justified by the Python language specification nor by common sense ;-) I'd suggest that this be changed in the tutorial. Furthermore I'd suggest that such use of Unicode literals throw errors instead. I'm assigning it to Martin, because he's one of the Unicode gurus :) ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-18 17:04 Message: Logged In: YES user_id=21627 The intended behaviour is that Unicode in the interactive mode "works", and assumes that the actual input is encoded according to the locale's encoding (i.e. sys.stdin.encoding). That isn't implemented, yet (and perhaps not even specified). However, it is most likely the case that this is a doc bug in ref manual, not in the tutorial. For this to work, the interactive mode needs to be able to pass the encoding to the parser, perhaps giving a Unicode object as the argument instead of a byte string (atleast IDLE might want to do that). Passing Unicode objects to eval/exec is for further study, though. ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2003-07-18 11:55 Message: Logged In: YES user_id=163326 Oh, I almost forgot about my original problem. Such behaviour shouldn't be encouraged in the tutorial any longer of course. Maybe I can find a better wording and submit a patch soonish. Now that I understand this better, assignnig this to myself :) ---------------------------------------------------------------------- Comment By: Gerhard Häring (ghaering) Date: 2003-07-18 11:54 Message: Logged In: YES user_id=163326 I *do* get the warnings when executing scripts, but I do *not* get the warnings at the interactive prompt. Lowering priority accordingly. Feel free to close this if this is indeed the intended behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773351&group_id=5470 From noreply@sourceforge.net Fri Jul 18 16:26:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 08:26:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-17 05:20 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 Category: Python Library >Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Just van Rossum (jvr) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-18 17:26 Message: Logged In: YES user_id=92689 I don't see how we can fix this for 2.2 without backporting universal newlines, so I'm very tempted to close this bug is "won't fix"... ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-18 15:37 Message: Logged In: YES user_id=619560 If that is the case, there is still a bug for usage in 2.2. Then you must make the changes as noted above or you will run into problems with DOS line endings on a Unix platform. Whether or not this must be fixed in the main library or whether those of us who bundle the code need to make the changes ourselves is up to those who manage Python. I am no longer concerned since it does work with Python 2.3. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-07-18 08:43 Message: Logged In: YES user_id=11105 FYI, I've filed patch 773179, which changes the compatibility requirements for modulefinder to >= Python 2.2. I don't want py2exe to support older versions anymore. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-18 00:24 Message: Logged In: YES user_id=619560 As it turns out, import.c has already been modified to handle universal line endings so this is not a bug for Python 2.3. It is rather a bug for Python 2.2 and lower. So I guess we should decide whether or not to remove the requirement for Python 1.5 support sooner rather than later. I can modify my own copy for Python 2.2 to handle this situation properly. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 19:09 Message: Logged In: YES user_id=619560 It is already incompatible since the removal of apply() took place a while back. I would not mind seeing the compat request removed. It removes constraints from future development. OTOH, the "U" stuff would have to be added to the imp module when it opens the file. Thus, the modulefinder.py file itself would not change. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-07-17 18:57 Message: Logged In: YES user_id=11105 Per the comment at the top of the file, modulefinder should be kept compatible with 1.5.2, so the "U" mode should be used with care ;-) OTOH, *I* requested the compatibility, and I no longer see a need for it. Should the compat request be removed? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:29 Message: Logged In: YES user_id=92689 Ah, imp :-(. 2.3: they're baking the release candidate today, so yeah, it's too late :-( ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 18:27 Message: Logged In: YES user_id=619560 The only problem is that the file is opened within the imp module when the find_module() method. So this means changes at the C level, right? And its already too late for Python 2.3?? I thought it was still two weeks away from release? Perhaps the simple fix with the replace() code can be used for now? I am not sure about the release strategy so I might be way off base here. :-) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:22 Message: Logged In: YES user_id=92689 This should be done with the "U" mode indeed. Can you provide a patch? It's too late for 2.3 anyway, so take your time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Fri Jul 18 16:32:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 08:32:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-16 21:20 Message generated for change (Comment added) made by atuining You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Just van Rossum (jvr) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- >Comment By: Anthony Tuininga (atuining) Date: 2003-07-18 09:32 Message: Logged In: YES user_id=619560 I personally don't have any problem with you closing this bug since it isn't a bug in Python 2.3. But then you might want to modify the proposed patch by Thomas to indicate that it only works in Python 2.3 and if you use it in Python 2.2, the problem with DOS line endings on Unix will appear. For those of us who care, we can make the one line change noted above and bundle it with our tools. So go ahead and close. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-18 09:26 Message: Logged In: YES user_id=92689 I don't see how we can fix this for 2.2 without backporting universal newlines, so I'm very tempted to close this bug is "won't fix"... ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-18 07:37 Message: Logged In: YES user_id=619560 If that is the case, there is still a bug for usage in 2.2. Then you must make the changes as noted above or you will run into problems with DOS line endings on a Unix platform. Whether or not this must be fixed in the main library or whether those of us who bundle the code need to make the changes ourselves is up to those who manage Python. I am no longer concerned since it does work with Python 2.3. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-07-18 00:43 Message: Logged In: YES user_id=11105 FYI, I've filed patch 773179, which changes the compatibility requirements for modulefinder to >= Python 2.2. I don't want py2exe to support older versions anymore. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 16:24 Message: Logged In: YES user_id=619560 As it turns out, import.c has already been modified to handle universal line endings so this is not a bug for Python 2.3. It is rather a bug for Python 2.2 and lower. So I guess we should decide whether or not to remove the requirement for Python 1.5 support sooner rather than later. I can modify my own copy for Python 2.2 to handle this situation properly. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 11:09 Message: Logged In: YES user_id=619560 It is already incompatible since the removal of apply() took place a while back. I would not mind seeing the compat request removed. It removes constraints from future development. OTOH, the "U" stuff would have to be added to the imp module when it opens the file. Thus, the modulefinder.py file itself would not change. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-07-17 10:57 Message: Logged In: YES user_id=11105 Per the comment at the top of the file, modulefinder should be kept compatible with 1.5.2, so the "U" mode should be used with care ;-) OTOH, *I* requested the compatibility, and I no longer see a need for it. Should the compat request be removed? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 10:29 Message: Logged In: YES user_id=92689 Ah, imp :-(. 2.3: they're baking the release candidate today, so yeah, it's too late :-( ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 10:27 Message: Logged In: YES user_id=619560 The only problem is that the file is opened within the imp module when the find_module() method. So this means changes at the C level, right? And its already too late for Python 2.3?? I thought it was still two weeks away from release? Perhaps the simple fix with the replace() code can be used for now? I am not sure about the release strategy so I might be way off base here. :-) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 10:22 Message: Logged In: YES user_id=92689 This should be done with the "U" mode indeed. Can you provide a patch? It's too late for 2.3 anyway, so take your time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Fri Jul 18 16:40:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 08:40:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-772763 ] modulefinder bug in load_module() Message-ID: Bugs item #772763, was opened at 2003-07-17 05:20 Message generated for change (Settings changed) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 Category: Python Library Group: Python 2.2 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Anthony Tuininga (atuining) Assigned to: Just van Rossum (jvr) Summary: modulefinder bug in load_module() Initial Comment: in revision 1.6 of file dist/src/Lib/modulefinder.py at line 265 there is a line that reads co = compile(fp.read()+'\n', pathname, 'exec') That line should read instead co = compile(fp.read().replace("\r\n", "\n") +'\n', pathname, 'exec') as otherwise files with Windows line endings do not compile correctly on Unix platforms. The import statement itself seems to handle this properly. Perhaps this can also be done with the universal line endings "U" option to the open command? ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-18 17:32 Message: Logged In: YES user_id=619560 I personally don't have any problem with you closing this bug since it isn't a bug in Python 2.3. But then you might want to modify the proposed patch by Thomas to indicate that it only works in Python 2.3 and if you use it in Python 2.2, the problem with DOS line endings on Unix will appear. For those of us who care, we can make the one line change noted above and bundle it with our tools. So go ahead and close. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-18 17:26 Message: Logged In: YES user_id=92689 I don't see how we can fix this for 2.2 without backporting universal newlines, so I'm very tempted to close this bug is "won't fix"... ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-18 15:37 Message: Logged In: YES user_id=619560 If that is the case, there is still a bug for usage in 2.2. Then you must make the changes as noted above or you will run into problems with DOS line endings on a Unix platform. Whether or not this must be fixed in the main library or whether those of us who bundle the code need to make the changes ourselves is up to those who manage Python. I am no longer concerned since it does work with Python 2.3. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-07-18 08:43 Message: Logged In: YES user_id=11105 FYI, I've filed patch 773179, which changes the compatibility requirements for modulefinder to >= Python 2.2. I don't want py2exe to support older versions anymore. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-18 00:24 Message: Logged In: YES user_id=619560 As it turns out, import.c has already been modified to handle universal line endings so this is not a bug for Python 2.3. It is rather a bug for Python 2.2 and lower. So I guess we should decide whether or not to remove the requirement for Python 1.5 support sooner rather than later. I can modify my own copy for Python 2.2 to handle this situation properly. ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 19:09 Message: Logged In: YES user_id=619560 It is already incompatible since the removal of apply() took place a while back. I would not mind seeing the compat request removed. It removes constraints from future development. OTOH, the "U" stuff would have to be added to the imp module when it opens the file. Thus, the modulefinder.py file itself would not change. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2003-07-17 18:57 Message: Logged In: YES user_id=11105 Per the comment at the top of the file, modulefinder should be kept compatible with 1.5.2, so the "U" mode should be used with care ;-) OTOH, *I* requested the compatibility, and I no longer see a need for it. Should the compat request be removed? ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:29 Message: Logged In: YES user_id=92689 Ah, imp :-(. 2.3: they're baking the release candidate today, so yeah, it's too late :-( ---------------------------------------------------------------------- Comment By: Anthony Tuininga (atuining) Date: 2003-07-17 18:27 Message: Logged In: YES user_id=619560 The only problem is that the file is opened within the imp module when the find_module() method. So this means changes at the C level, right? And its already too late for Python 2.3?? I thought it was still two weeks away from release? Perhaps the simple fix with the replace() code can be used for now? I am not sure about the release strategy so I might be way off base here. :-) ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-17 18:22 Message: Logged In: YES user_id=92689 This should be done with the "U" mode indeed. Can you provide a patch? It's too late for 2.3 anyway, so take your time... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772763&group_id=5470 From noreply@sourceforge.net Fri Jul 18 17:22:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 09:22:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-773476 ] import site fails in certain embedding situations Message-ID: Bugs item #773476, was opened at 2003-07-18 03:52 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: Accepted Priority: 8 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: import site fails in certain embedding situations Initial Comment: In certain situations (python23.dll and python23.zip in the same dir, no PYTHON related env vars set, no Python registry values), Python will fail to import site. Exception is: import site # loaded from Zip C:\build\mozilla\dist\bin\python23.zip\site.pyo 'import site' failed; traceback: Traceback (most recent call last): File ".\site.py", line 191, in ? NameError: name 'sitedir' is not defined This exception is the result of there being no "prefixes", so sitedir is never bound to a value. This, the del of sitedir fails. Suggested patch is attached (just setting sitedir to None before the loop) ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-18 12:22 Message: Logged In: YES user_id=6380 Looks good to me, OK to check in AFAIC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-18 09:45 Message: Logged In: YES user_id=80475 Then None it is. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-18 09:29 Message: Logged In: YES user_id=14198 The exception is "sitedir" - but I do concede a better patch would involve sitedirs=[]; sitedir=None and zapping both. However, as site is executed as a standard module, the cleanup of the namespace seems a little anal - especially now we have __all__ - so maybe deleting the dels would be better still But given we are so close to release, and that the 'noun' in the exception is singular, I still prefer None (but I would be happy to settle for sitedir="winK" #wink) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-18 04:06 Message: Logged In: YES user_id=80475 "sitedir = []" would be a better choice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 From noreply@sourceforge.net Fri Jul 18 19:24:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 18 Jul 2003 11:24:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-773476 ] import site fails in certain embedding situations Message-ID: Bugs item #773476, was opened at 2003-07-18 03:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 8 Submitted By: Mark Hammond (mhammond) >Assigned to: Jeremy Hylton (jhylton) Summary: import site fails in certain embedding situations Initial Comment: In certain situations (python23.dll and python23.zip in the same dir, no PYTHON related env vars set, no Python registry values), Python will fail to import site. Exception is: import site # loaded from Zip C:\build\mozilla\dist\bin\python23.zip\site.pyo 'import site' failed; traceback: Traceback (most recent call last): File ".\site.py", line 191, in ? NameError: name 'sitedir' is not defined This exception is the result of there being no "prefixes", so sitedir is never bound to a value. This, the del of sitedir fails. Suggested patch is attached (just setting sitedir to None before the loop) ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-18 14:24 Message: Logged In: YES user_id=31435 Closing, as Jeremy said he applied this for 2.3c1. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-07-18 12:22 Message: Logged In: YES user_id=6380 Looks good to me, OK to check in AFAIC. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-18 09:45 Message: Logged In: YES user_id=80475 Then None it is. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-18 09:29 Message: Logged In: YES user_id=14198 The exception is "sitedir" - but I do concede a better patch would involve sitedirs=[]; sitedir=None and zapping both. However, as site is executed as a standard module, the cleanup of the namespace seems a little anal - especially now we have __all__ - so maybe deleting the dels would be better still But given we are so close to release, and that the 'noun' in the exception is singular, I still prefer None (but I would be happy to settle for sitedir="winK" #wink) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-18 04:06 Message: Logged In: YES user_id=80475 "sitedir = []" would be a better choice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773476&group_id=5470 From noreply@sourceforge.net Sat Jul 19 12:00:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 04:00:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-773356 ] posix needs to generate unicode filenames where necessary Message-ID: Bugs item #773356, was opened at 2003-07-18 02:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773356&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: posix needs to generate unicode filenames where necessary Initial Comment: Mac OS X supports Unicode filenames. At the moment this can't be enabled because when raising an IOError the filename embedded in the IOError exception (and perhaps others) is a plain string. This attribute should be a unicode object where necessary. This can be demonstrated by building on Mac OS X with the last line of posixpath.py replaced with if sys.platform == "darwin": supports_unicode_filenames = True else: supports_unicode_filenames = False and running the interpreter against Lib/test/test_pep277.py. This needs to be corrected after the 2.3 release. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-19 13:00 Message: Logged In: YES user_id=21627 Python should not generate Unicode strings for the exceptions at all. Instead, it should return the very same strings in the exceptions that the user was passing in the posix operations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773356&group_id=5470 From noreply@sourceforge.net Sat Jul 19 14:49:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 06:49:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-774188 ] XP manifest files should be installed Message-ID: Bugs item #774188, was opened at 2003-07-19 15: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=774188&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Henk Punt (h_punt) Assigned to: Tim Peters (tim_one) Summary: XP manifest files should be installed Initial Comment: In order for python based windows programs to use the right widget (e.g. common control) versions on XP, a manifest file must be present for both executables (python.exe and pythonw.exe). I believe Python2.2 installs these per default. If these are not present, weird graphical artifacts may show up on windows XP in tree and list controls when high-color icons are used. A sample of a manifest file ('pythonw.exe.manifest'): Python Interpreter ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774188&group_id=5470 From noreply@sourceforge.net Sat Jul 19 16:36:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 08:36:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-231207 ] Fatal Python Error during program shutdown Message-ID: Bugs item #231207, was opened at 2001-02-06 03:50 Message generated for change (Comment added) made by dcbbcd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Doug Henderson (djhender) Assigned to: Nobody/Anonymous (nobody) Summary: Fatal Python Error during program shutdown Initial Comment: The windows builds of versions 2.0 and 2.1a2 contain an intermittent bug which often appears when a script using Tkinter stops by calling self.tk.quit() and sometimes (less often) appears following a event or call to a ?.destory() function. Under Windows 98SE, this results in a GPF. Under Windows 2000, a message to the console window shows "Fatal Python Error", "PyEval_RestoreThread NULL tstate". The following script demonstrates the problem: --------------------- # BugDemo.py from Tkinter import * class BugDemo(Frame): def __init__(self, parent): Frame.__init__(self, parent) Button(self, text='Hi', command=self.hi).pack() Button(self, text='Quit', command=self.tk.quit).pack() def hi(self): print "hi" bd = BugDemo(Tk()) bd.pack() bd.mainloop() ---------------------- Execute in console window: "c:> python BugDemo.py" Test this by 1) clicking Quit button 2) clicking Hi button, then Quit button. Test 1: The script runs successfully most of the time. I found I had to minimize and restore its window to make it fail regularly. Test 2: I need to click Hi button before clicking the Quit button. Then it failed about half the time. The problem appears to occur after the script has completed, during some kind of cleanup perhaps. The more useful error message on the Win2k machine may help to locate the problem. Problem also manifests using the PythonWare 2.0 release on Win98. ---------------------------------------------------------------------- Comment By: Dennis Benzinger (dcbbcd) Date: 2003-07-19 17:36 Message: Logged In: YES user_id=826043 Python reliably crashes on Win XP - SP1 with the following test program too: import Tkinter tk = Tkinter.Tk() quit_btn = Tkinter.Button(tk, text='quit', #command=tk.quit) # This crashs command=tk.destroy) # This works quit_btn.pack() Tkinter.mainloop() The error message is something like (bad english translation): The instruction in "0x77f4b2ab" points to "0x00000028". The memory can't be read. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-11-07 15:58 Message: Logged In: YES user_id=6380 idiscovery, when you say "PythonWin" do you actually mean Pythonwin (a Win32-specific Python IDE, part of Mark Hammond's win32all)? Or do you simple mean "Python under Windows", as installed by the Python installer you get from python.org? This difference is significant; I would not expect Tkinter apps to work well using Pythonwin, because it has its own Win32 event loop. ---------------------------------------------------------------------- Comment By: Doug Henderson (djhender) Date: 2002-11-04 19:12 Message: Logged In: YES user_id=148444 I modified my BugDemo program to change the last 3 lines to root = Tk() bd = BugDemo(root) bd.pack() bd.mainloop() root.destory() This did not resolve the problem under Win98SE Python 2.2.1. Both Python 2.2.1 and 2.2.2 use Tk/tcl 8.3. I have seen comments that indicate that this is a known problem in stock 8.3 which is fixed in 8.4. I also tested using the other two scripts presented elsewhere among the comments to this bug report. These tests also hang, even with the added root.destroy() statement. I no longer have access to a Win2k machine, so I cannot test there. ---------------------------------------------------------------------- Comment By: Internet Discovery (idiscovery) Date: 2002-11-03 07:52 Message: Logged In: YES user_id=33229 I know I'm a Python newbie but I know Tcl well and I think I know at least part of what's going on. Looking specifically at nobody's 2002-04-22 14:21 code, I see that this uses mainloop and quit in a way that many Python books and examples do, as if quit() will "Quit the Tcl interpreter. All widgets will be destroyed." But if you look at MainLoop and Quit in _tkinter.c you see that Quit just sets a variable that causes MainLoop to end - it doesn't destroy anything nor quit the interpreter. IMHO all Tkinter programs need a root.destroy() after root.mainloop() If you change nobody's program to add a root.destroy() it runs fine under PythonWin. The "bug" is in the documentation of quit() in Tkinter.py def quit(self): """Quit the Tcl interpreter. All widgets will be destroyed.""" self.tk.quit() The comment should read """Quit the main event loop. It is up to you to call root.destroy() after.""" If I'm right the documentation for Tkinter in the library reference should be changed too; there should be a root.destroy() at the end of http://www.python.org/doc/2.2.1/lib/node503.html If I'm right then I'll stick my neck out a little further: Tkinter's mainloop and quit should be dropped from _tkinter.c and replaced with the following idiom and usage: In Tkinter.py declare a class variable in Misc: _exit = -1 and change in Misc TCL_ALL_EVENTS = 0 def quit(self): """Quit the Tcl interpreter. All widgets will be destroyed.""" self._exit = 0 def mainloop(self): """Loop until we call quit()""" while self._exit < 0: try: self.root.tk.dooneevent(TCL_ALL_EVENTS) except SystemExit: #print 'Exit' self.exit = 1 break except # do something intelligent with errors or interrupts I believe this is more transparent and more open to creativity. I have experimented (all my code is like this now) and feel that there is no performance penalty to looping in Python. In addition it avoids the 20msec sleep in _tkinter.mainloop() that is an abomination. It would also allow people to think more clearly about what happens when you have 2 Tk() instances, in which case you have 2 Tcl interpeters. It may make you move _exit to be an instance variable of the Tk class. In any event you'll be able to see what's going on. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-04-22 16:21 Message: Logged In: NO I confirm the behaviour for: WinNT 4.0 SP5 tested with Python 2.2Beta1 (ActiveState) tested with Python 2.2.1.222 (ActiveState) PythonWinIDE will hang when the following program is "quit"ted. But will "quit" normally when run standalone (not within PythonWinIDE): # # from Tkinter import * from tkMessageBox import * class App: def __init__(self, winRoot): frame = Frame(winRoot) frame.pack() self.btnQuit = Button(frame, text="QUIT", bg="blue", foreground="light blue", command=frame.quit) self.btnQuit.pack(side=LEFT) self.btnHiThere = Button(frame, text="Hi there!",command=self.sayHiThere) self.btnHiThere.pack(side=LEFT) def sayHiThere(self): showinfo("Greeting", "Hi There") if __name__ == "__main__": root = Tk() test = App(root) root.mainloop() ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2002-03-01 23:49 Message: Logged In: YES user_id=31392 Unassign as it appears that effbot isn't going to look at it. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-07-18 13:13 Message: Logged In: NO i won't to be a hacker ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-05-29 09:30 Message: Logged In: NO Note: I am running Windows98 ActivePython 2.1 Even with console apps in python this same error appears I tried using another Distribution of Python for win32, PythonWare20 So this leads me to believe that some lib is missing on win98. Because at work I use Win95, and Installed ActivePython 2.1, and it works fine and dandy ---------------------------------------------------------------------- Comment By: Joel Gould (joelgould) Date: 2001-03-24 17:52 Message: Logged In: YES user_id=20954 I also see a GPF on shutdown under Windows 98 using Tkinter. I tested this using the PythonWare 2.0 release as well. I have attached a very simple Tkinter program. When I run this on my Windows 98 SE machine, a crash occurs when the program exits. Without the MainDialog class it works OK. Without the Pmw initialization call it works OK. But as written it will crash around 75% of the time. (1) run the program (2) press the Test Button (3) click Cancel in the file open dialog (you do not need to select a file) (4) click the close button in the upper right corner --> Boom -------------------- import Tkinter import tkFileDialog import Pmw def action(): tkFileDialog.askopenfilename(filetypes=[('All','*')]) class MainDialog: def __init__(self,parent): Tkinter.Button(parent,text='Test Button',command=action).pack() root = Pmw.initialise() dialog = MainDialog(root) root.mainloop() ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2001-02-10 00:34 Message: Assigned to /F, under the theory he can confirm that "this kind of thing" is still a general problem with Tk we can't do anything about. ---------------------------------------------------------------------- Comment By: Doug Henderson (djhender) Date: 2001-02-06 06:30 Message: See also #116289 (and my comment to it) which describes what often happened to my 'real' programs which lead to developing the above BugDemo script. My 'real' programs were developed over the last two years or so, and worked in Jan 2000 with 1.5.2. I upgraded the Python version recently, and then started working on these programs again. It was "WTF is wrong with my code", until I found the same problem showing up in the small test cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470 From noreply@sourceforge.net Sat Jul 19 20:10:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 12:10:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-768391 ] hardcoded python paths Message-ID: Bugs item #768391, was opened at 2003-07-09 06:39 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768391&group_id=5470 >Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 3 Submitted By: Tiago Castro Henriques (tiagoh) >Assigned to: Kurt B. Kaiser (kbk) Summary: hardcoded python paths Initial Comment: I tried to use the new version of idle that is now integrated into 2.3b2, but I got an error when I tried to run /usr/local/lib/python2.3/idlelib/idle: % /usr/local/lib/python2.3/idlelib/idle Traceback (most recent call last): File "./idle", line 8, in ? import PyShell File "./PyShell.py", line 19, in ? from Tkinter import * File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 35, in ? import _tkinter # If this fails your Python may not be configured for Tk ImportError: No module named _tkinter I'm using python2.3b2 on MacOSX 10.2.6, compiled from source with standard options. Apparently the builtin 2.2 version of Python is being used, even though $PYTHONHOME is not set (according to the manpages, this should make it default to /usr/local, and not /usr as seems to be the case). This is due to the fact that this executable script contains a shebang declaration with a hardcoded python path: % head -1 /usr/local/lib/python2.3/idlelib/idle #!/usr/bin/python This should be replaced by the standard shebang declaration: #! /usr/bin/env python I checked to see if there were any other *.py files in /usr/local/lib/python2.3 suffering from similar problems, and found the following files to be affected: /usr/local/lib/python2.3/cgi.py: #! /usr/local/bin/python /usr/local/lib/python2.3/test/test_bz2.py: #!/usr/bin/python /usr/local/lib/python2.3/test/test_largefile.py: #!python /usr/local/lib/python2.3/test/test_optparse.py: #!/usr/bin/python The files /usr/local/bin/idle, /usr/local/bin/pydoc and /usr/local/bin/pycolor also have a hardcoded python path: % head -1 idle pycolor pydoc ==> idle <== #!/usr/local/bin/python ==> pycolor <== #!/usr/local/bin/python ==> pydoc <== #!/usr/local/bin/python These should similarly be changed to #! /usr/bin/env python ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768391&group_id=5470 From noreply@sourceforge.net Sat Jul 19 21:15:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 13:15:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-774188 ] XP manifest files should be installed Message-ID: Bugs item #774188, was opened at 2003-07-19 09: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=774188&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Henk Punt (h_punt) >Assigned to: Mark Hammond (mhammond) Summary: XP manifest files should be installed Initial Comment: In order for python based windows programs to use the right widget (e.g. common control) versions on XP, a manifest file must be present for both executables (python.exe and pythonw.exe). I believe Python2.2 installs these per default. If these are not present, weird graphical artifacts may show up on windows XP in tree and list controls when high-color icons are used. A sample of a manifest file ('pythonw.exe.manifest'): Python Interpreter ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-19 16:15 Message: Logged In: YES user_id=31435 Mark, does this mean anything to you? We've (PLabs) certainly never installed anything like this before. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774188&group_id=5470 From noreply@sourceforge.net Sat Jul 19 23:25:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 15:25:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-774188 ] XP manifest files should be installed Message-ID: Bugs item #774188, was opened at 2003-07-19 15:49 Message generated for change (Comment added) made by h_punt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774188&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Henk Punt (h_punt) Assigned to: Mark Hammond (mhammond) Summary: XP manifest files should be installed Initial Comment: In order for python based windows programs to use the right widget (e.g. common control) versions on XP, a manifest file must be present for both executables (python.exe and pythonw.exe). I believe Python2.2 installs these per default. If these are not present, weird graphical artifacts may show up on windows XP in tree and list controls when high-color icons are used. A sample of a manifest file ('pythonw.exe.manifest'): Python Interpreter ---------------------------------------------------------------------- >Comment By: Henk Punt (h_punt) Date: 2003-07-20 00:25 Message: Logged In: YES user_id=729698 I may have put them there myself, It is a known problem though, lookup section '2.4.2.1 Windows XP and Python 2.2.2' of the wxpython Wiki at: http://wiki.wxpython.org/index.cgi/Frequently_20Asked_20Que stions It would not hurt to have these installed by default for the Windows platform ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-19 22:15 Message: Logged In: YES user_id=31435 Mark, does this mean anything to you? We've (PLabs) certainly never installed anything like this before. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774188&group_id=5470 From noreply@sourceforge.net Sun Jul 20 00:44:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 16:44:03 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-726152 ] Website request Message-ID: Feature Requests item #726152, was opened at 2003-04-23 04:35 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=726152&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: David Abrahams (david_abrahams) Assigned to: Nobody/Anonymous (nobody) Summary: Website request Initial Comment: A link to the SourceForge project page on the website would be a big help, especially to those of us who keep getting told to "submit a bug report to the SF tracker" ;-) ---------------------------------------------------------------------- Comment By: David Abrahams (david_abrahams) Date: 2003-05-06 21:27 Message: Logged In: YES user_id=52572 Sorry, I meant on the main page. I've never even been tempted to look at the page you cite. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-06 20:12 Message: Logged In: YES user_id=33168 There are 2 on this page: http://www.python.org/dev/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=726152&group_id=5470 From noreply@sourceforge.net Sun Jul 20 01:16:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 17:16:06 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-708125 ] Requesting Mock Object support for unittest.TestCase Message-ID: Feature Requests item #708125, was opened at 2003-03-22 15:05 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=708125&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Russell (mattruss) Assigned to: Nobody/Anonymous (nobody) Summary: Requesting Mock Object support for unittest.TestCase Initial Comment: I previously submitted a patch (sf id 706590), since I was following www.python.com's notes on how to contribute - since using sf more i think i should of added it to this RFE. Since posting the orignal patch I have updated the code based upon sugestions from python-dev and others. please view my origanal patch here: https://sourceforge.net/tracker/index.php? func=detail&aid=706590&group_id=5470&atid=305470 This patch adds one method - createMockInstance (classDef, overrides, *initArgs, **initKwds) to unittest.TestCase, and two classes MockFactory and MockMethod. Since both these classes should never really be used outside the scope of a unittest, I thought it best to add them to the unittest module (allthough it is getting rather big - should be split into a package?) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-19 19:16 Message: Logged In: YES user_id=80475 Matthew, thanks for the patch. It gets a little better with each update (though it is still in dire need of a spell-check). The cost/benefit of adding this to the unittest module is not clear. Perhaps, it would be worthwhile to present it on the newsgroup to tease out the idea, build a fan club for it, or come up with a simpler API. My biggest issue with the unittest module is that it is already too extensive. One has to read a small book on the subject to get started. The number of doc pages, classes, and methods rank it as more complex than most of the net modules (with the notable exception of the email package). In Beck's TDD book (p. 119), he comments that some unittest packages are already too complicated for his tastes. This patch would make the complexity issue worse. It takes longer to figure out how the use the patch that it does to create a small, easy-to-read, special purpose mock object. Also, I'm concerned that MockObjects tend to create a false sense of security in a situation where the actual object behavior diverges from the simulated behavior. Also, to the extent that a simulation is simple, it tends to discourage adding tests that exercise all the nuances of a real object. For example, a MockDatabase may simulate the expected replies to some queries but doesn't behave enough like the real thing to encourge tests on commits, rollbacks, cache flushing, re-ordered tables, etc. If this doesn't get added to the unittest module, it would certainly be worthwhile to post it to the Python Cookbook so that advanced users can get to it when they need it. ---------------------------------------------------------------------- Comment By: Matthew Russell (mattruss) Date: 2003-04-09 19:32 Message: Logged In: YES user_id=737261 I wrote these unittests first before i wrote the code. Hopefully proves that it works for new style classes and old (allthought tests are now a little out of date as the updated diff uses sets, therefore is 2.3 specific) ---------------------------------------------------------------------- Comment By: Matthew Russell (mattruss) Date: 2003-04-09 17:53 Message: Logged In: YES user_id=737261 I have made some changes to my patch - i hope it's made things clearer (?) have also replaced 0/1's with False/True where appropriate added boolean kwd arg to main - exitsOnResult which if set to false will not do sys.exit (now you can run python -i test_mystuff.py using this and not be thrown back out to the command line) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=708125&group_id=5470 From noreply@sourceforge.net Sun Jul 20 01:30:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 17:30:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-763708 ] Failures in test_macostools Message-ID: Bugs item #763708, was opened at 2003-07-01 08:54 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-20 02:30 Message: Logged In: YES user_id=45365 This seems to be fixed in 2.3c1. Could you please test? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 20:03 Message: Logged In: YES user_id=357491 OK, so the problem seems to be coming from Mac/Modules/file/ _Filemodule.c and the File_FSGetResourceForkName function (printing the result just prints "ERROR"). The online docs for FSGetResourceForkName (which is pretty much all that is called in that function) can be found at http://developer.apple.com/ documentation/Carbon/Reference/File_Manager/file_manager/ function_group_20.html#//apple_ref/c/func/ FSGetResourceForkName . Now it looks like the error is an OS X error and has nothing to do with Python. The error (-1402) means that the fork name is syntactically invalid. I don't see how this can mean anything, though, since FSGetResourceForkName's only argument is a pointer to store the result of the call into. The only thing I can think of that might be causing this error from Python's side is that a resource fork does not exist when the call is made. But this is just a guess so I could be wrong. Jack, I am going to be gone from July 13 until July 21, so if you need any debugging info from me before 2.3 final goes out I am afraid it will have to happen soon. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 22:42 Message: Logged In: YES user_id=357491 OK, Jack, here is your info: - 10.2.6 - Python 2.3b2+ straight from CVS (only way to code =) - HFS+ I believe (Finder says my HD is Mac OS Extended) Ran the test from my CVS tree with my installed version of Python 2.3b2+ (I can't do anything the standard way). I just ran it with the installed copy from the installed test directory and got the errors. I also just ran it with the compiled copy but not installed Python executable in my CVS tree and once again got the error. I noticed this came up, for me at least, when I was checking a patch for posixpath.py (which was applied to CVS). I checked the code, though, and didn't find a problem where anything changed to posixpath.py would affect it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 13:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply@sourceforge.net Sun Jul 20 01:45:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 17:45:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-774411 ] Typo in socket documentation Message-ID: Bugs item #774411, was opened at 2003-07-20 12:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774411&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: Typo in socket documentation Initial Comment: Towards the end of the page, it says that sockets can be in three modes - nonblocking, blocking and timout. Unless this is some clever reference to Tim ;) timout should probably be timeout. (Apologies if this is fixed in cvs; cvs access is so crappy it's hard to check). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774411&group_id=5470 From noreply@sourceforge.net Sun Jul 20 02:11:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 18:11:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-774411 ] Typo in socket documentation Message-ID: Bugs item #774411, was opened at 2003-07-19 19:45 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774411&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Tony Meyer (anadelonbrin) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in socket documentation Initial Comment: Towards the end of the page, it says that sockets can be in three modes - nonblocking, blocking and timout. Unless this is some clever reference to Tim ;) timout should probably be timeout. (Apologies if this is fixed in cvs; cvs access is so crappy it's hard to check). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-19 20:11 Message: Logged In: YES user_id=80475 Fixed. See Doc/lib/libsocket.tex 1.76 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774411&group_id=5470 From noreply@sourceforge.net Sun Jul 20 02:20:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 18:20:35 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-694339 ] Dedenting with Shift+Tab Message-ID: Feature Requests item #694339, was opened at 2003-02-27 08:08 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=694339&group_id=5470 Category: IDLE Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel (kamek) Assigned to: Nobody/Anonymous (nobody) Summary: Dedenting with Shift+Tab Initial Comment: IDLE already provides quick block indenting, by selecting one or more lines and pressing Tab. So, it would make sense to have Shift+Tab to do the opposite work. While there's already Alt+[ (and Alt+] to indent), Shift+Tab is more intuitive, especially to those who are used to other Windows developer tools, like Visual Studio or TextPad. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-19 20:20 Message: Logged In: YES user_id=80475 While you get used to it quickly, I've bumped in to this also. It is nice to have the control keys work the same across applications. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=694339&group_id=5470 From noreply@sourceforge.net Sun Jul 20 03:16:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 19:16:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-768306 ] Distutils broken on Os X Message-ID: Bugs item #768306, was opened at 2003-07-09 03:28 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768306&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Rueger (torstenrueger) Assigned to: Jack Jansen (jackjansen) Summary: Distutils broken on Os X Initial Comment: Os X 10.2.6. Python 2.3b2 from http://homepages.cwi.nl/~jack/ macpython.html#beta Trying to comiple py-xml-rpc 2.8.3 from http:// sourceforge.net/projects/py-xmlrpc/ I get a ton of multiple defined symbols like: ld: multiple definitions of symbol _rpcBase64Type build/temp.darwin-6.6-Power_Macintosh-2.3/src/rpcBase64.o definition of _rpcBase64Type in section (__DATA,__data) build/temp.darwin-6.6-Power_Macintosh-2.3/src/ rpcBoolean.o definition of _rpcBase64Type in section (__DATA,__common) ld: multiple definitions of symbol _rpcBoolType ..... I tracked this down to the presence of the compile flag "- fno-common" used by the distutils. The man page for gcc states quite clearly that this is not usually an advisable flag, quote: -fno-common In C, allocate even uninitialized global variables in the data section of the object file, rather than gen- erating them as common blocks. This has the effect that if the same variable is declared (without "extern") in two different compilations, you will get an error when you link them. The only reason this might be useful is if you wish to verify that the pro- gram will work on other systems which always work this way. I have compiled and linked all files with the makefile that is also distributed in py-xmlrpc, but I had to change the link options to "-flat_namespace -undefined warning". I can help in testing a fix if someone can assist with distutils knowledge. Torsten ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-19 21:16 Message: Logged In: YES user_id=44345 Works for me (python setup.py install ; python -c 'import xmlrpc'). I don't see -fnocommon in the gcc flags. This is with a Unix-style build of Python, not a framework build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768306&group_id=5470 From noreply@sourceforge.net Sun Jul 20 05:40:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 19 Jul 2003 21:40:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-774188 ] XP manifest files should be installed Message-ID: Bugs item #774188, was opened at 2003-07-19 23:49 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774188&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Henk Punt (h_punt) Assigned to: Mark Hammond (mhammond) Summary: XP manifest files should be installed Initial Comment: In order for python based windows programs to use the right widget (e.g. common control) versions on XP, a manifest file must be present for both executables (python.exe and pythonw.exe). I believe Python2.2 installs these per default. If these are not present, weird graphical artifacts may show up on windows XP in tree and list controls when high-color icons are used. A sample of a manifest file ('pythonw.exe.manifest'): Python Interpreter ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-07-20 14:40 Message: Logged In: YES user_id=14198 Welcome to .NET . I can believe this would help some GUI programs, but am hard pressed to call it critical enough to bang in 2.3 at this late stage. A concern is that how do we know the assertion about what control library we want to use is true for *all* programs hosted by our executables? ---------------------------------------------------------------------- Comment By: Henk Punt (h_punt) Date: 2003-07-20 08:25 Message: Logged In: YES user_id=729698 I may have put them there myself, It is a known problem though, lookup section '2.4.2.1 Windows XP and Python 2.2.2' of the wxpython Wiki at: http://wiki.wxpython.org/index.cgi/Frequently_20Asked_20Que stions It would not hurt to have these installed by default for the Windows platform ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-20 06:15 Message: Logged In: YES user_id=31435 Mark, does this mean anything to you? We've (PLabs) certainly never installed anything like this before. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774188&group_id=5470 From noreply@sourceforge.net Sun Jul 20 08:24:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 00:24:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-774480 ] 2.3c1 readme unparseable sentence Message-ID: Bugs item #774480, was opened at 2003-07-20 00:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774480&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neil T. Spring (bluehal) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3c1 readme unparseable sentence Initial Comment: In the section "Building a shared libpython": "In particular, the library likely object files using position-independent code (PIC) if PIC flags are needed for the shared library." I expect something goes between "likely" and "object," but I don't know what it might be. My guess (without actually knowing how it works) is that the paragraph should read: If you enable this feature, the same object files will be used to create a static library as well from the same object files. Note that these objects will consist of position-independent code (PIC) on platforms where PIC flags are needed for the shared library. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774480&group_id=5470 From noreply@sourceforge.net Sun Jul 20 09:36:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 01:36:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-774188 ] XP manifest files should be installed Message-ID: Bugs item #774188, was opened at 2003-07-19 15:49 Message generated for change (Comment added) made by h_punt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774188&group_id=5470 Category: Windows Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Henk Punt (h_punt) Assigned to: Mark Hammond (mhammond) Summary: XP manifest files should be installed Initial Comment: In order for python based windows programs to use the right widget (e.g. common control) versions on XP, a manifest file must be present for both executables (python.exe and pythonw.exe). I believe Python2.2 installs these per default. If these are not present, weird graphical artifacts may show up on windows XP in tree and list controls when high-color icons are used. A sample of a manifest file ('pythonw.exe.manifest'): Python Interpreter ---------------------------------------------------------------------- >Comment By: Henk Punt (h_punt) Date: 2003-07-20 10:36 Message: Logged In: YES user_id=729698 I've googled around a bit more, http://www.python.org/cgi-bin/moinmoin/PythonQuestions section '4 Windows XP look-and-feel' advises against it, apparently somebody ran into problems with this. Mark is right, we don't know what the right control library is for any program run with the python.exe interpreter. sigh, I guess for microsoft a program is only a program when it is an .exe :-(. As far as I am concerned this is also not very critical. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-20 06:40 Message: Logged In: YES user_id=14198 Welcome to .NET . I can believe this would help some GUI programs, but am hard pressed to call it critical enough to bang in 2.3 at this late stage. A concern is that how do we know the assertion about what control library we want to use is true for *all* programs hosted by our executables? ---------------------------------------------------------------------- Comment By: Henk Punt (h_punt) Date: 2003-07-20 00:25 Message: Logged In: YES user_id=729698 I may have put them there myself, It is a known problem though, lookup section '2.4.2.1 Windows XP and Python 2.2.2' of the wxpython Wiki at: http://wiki.wxpython.org/index.cgi/Frequently_20Asked_20Que stions It would not hurt to have these installed by default for the Windows platform ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-19 22:15 Message: Logged In: YES user_id=31435 Mark, does this mean anything to you? We've (PLabs) certainly never installed anything like this before. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774188&group_id=5470 From noreply@sourceforge.net Sun Jul 20 12:59:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 04:59:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-774536 ] UnicodeError Message-ID: Bugs item #774536, was opened at 2003-07-20 13: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=774536&group_id=5470 Category: Parser/Compiler Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Peternell (mpeti) Assigned to: Nobody/Anonymous (nobody) Summary: UnicodeError Initial Comment: >>> c = "Österreich" UnicodeError: ASCII encoding error: ordinal not in range(128) the parser must not consider the German language an error. the same for French: >>> c = "Kate Ryan - Désenchantée" UnicodeError: ASCII encoding error: ordinal not in range(128) I think this behavior was INTENDED, or why did the error message say "ordinal not in range(128)"? This is not an error. It is intended that bytes have 8 bits and not 7. I hope you don't reject this bug. Michael ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774536&group_id=5470 From noreply@sourceforge.net Sun Jul 20 13:29:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 05:29:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-774546 ] popen does not like filenames with spaces Message-ID: Bugs item #774546, was opened at 2003-07-20 14:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774546&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: popen does not like filenames with spaces Initial Comment: The argument for the target executable are passed as a string to popen. The problem is that with filenames which contains spaces, the argument breaking routine will fail and create two arguments for one filename. It would be more convenient if one could pass the argument to popen as a list of string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774546&group_id=5470 From noreply@sourceforge.net Sun Jul 20 15:15:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 07:15:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-774536 ] UnicodeError Message-ID: Bugs item #774536, was opened at 2003-07-20 13:59 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774536&group_id=5470 Category: Parser/Compiler Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Peternell (mpeti) Assigned to: Nobody/Anonymous (nobody) Summary: UnicodeError Initial Comment: >>> c = "Österreich" UnicodeError: ASCII encoding error: ordinal not in range(128) the parser must not consider the German language an error. the same for French: >>> c = "Kate Ryan - Désenchantée" UnicodeError: ASCII encoding error: ordinal not in range(128) I think this behavior was INTENDED, or why did the error message say "ordinal not in range(128)"? This is not an error. It is intended that bytes have 8 bits and not 7. I hope you don't reject this bug. Michael ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-07-20 16:15 Message: Logged In: YES user_id=38388 Are you sure about this ? /home/lemburg> python2.2 Python 2.2.3 (#1, Jul 1 2003, 10:54:49) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> c = "Österreich" >>> Same for Python 2.3. Perhaps you have change something in your site.py file ?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774536&group_id=5470 From noreply@sourceforge.net Sun Jul 20 17:03:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 09:03:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-774536 ] UnicodeError Message-ID: Bugs item #774536, was opened at 2003-07-20 13:59 Message generated for change (Comment added) made by mpeti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774536&group_id=5470 Category: Parser/Compiler Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Peternell (mpeti) Assigned to: Nobody/Anonymous (nobody) Summary: UnicodeError Initial Comment: >>> c = "Österreich" UnicodeError: ASCII encoding error: ordinal not in range(128) the parser must not consider the German language an error. the same for French: >>> c = "Kate Ryan - Désenchantée" UnicodeError: ASCII encoding error: ordinal not in range(128) I think this behavior was INTENDED, or why did the error message say "ordinal not in range(128)"? This is not an error. It is intended that bytes have 8 bits and not 7. I hope you don't reject this bug. Michael ---------------------------------------------------------------------- >Comment By: Michael Peternell (mpeti) Date: 2003-07-20 18:03 Message: Logged In: YES user_id=809932 Hi lemburg, no, I haven't. It seems the problem only exists on Windows. I am using Windows XP. Look at this URL: http://www.python.org/doc/current/tut/node5.html (Chapter 3.1.3): "...The default encoding is normally set to ASCII, which passes through characters in the range 0 to 127 and rejects any other characters with an error. ..." But they are writing strings in the form u"blabla". Maybe Windows converts everything to Unicode automatically? But thank you anyways. The problem only exists with 2.2.3 and only with Idle. The Dos-Version (python.exe) works proplerly. I've downloaded python 2.3c1 now and everything works fine. But it isn't perfect anyways... >>> x = "Österreich" >>> x '\xd6sterreich' >>> print x Österreich >>> "ññ" '\xf1\xf1' '\xd6' doesn't look very nice, but as long as you can print it, it's not a big problem. and it can parse char(0xf1) (or Alt-164, which equals 0xa4) too. Michael ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-07-20 16:15 Message: Logged In: YES user_id=38388 Are you sure about this ? /home/lemburg> python2.2 Python 2.2.3 (#1, Jul 1 2003, 10:54:49) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> c = "Österreich" >>> Same for Python 2.3. Perhaps you have change something in your site.py file ?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774536&group_id=5470 From noreply@sourceforge.net Sun Jul 20 17:17:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 09:17:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-774536 ] UnicodeError Message-ID: Bugs item #774536, was opened at 2003-07-20 13:59 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774536&group_id=5470 >Category: IDLE Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Michael Peternell (mpeti) Assigned to: Nobody/Anonymous (nobody) Summary: UnicodeError Initial Comment: >>> c = "Österreich" UnicodeError: ASCII encoding error: ordinal not in range(128) the parser must not consider the German language an error. the same for French: >>> c = "Kate Ryan - Désenchantée" UnicodeError: ASCII encoding error: ordinal not in range(128) I think this behavior was INTENDED, or why did the error message say "ordinal not in range(128)"? This is not an error. It is intended that bytes have 8 bits and not 7. I hope you don't reject this bug. Michael ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2003-07-20 18:17 Message: Logged In: YES user_id=38388 Ah, so it's an IDLE problem, not a Python one. AFAIK, IDLE behaves much better wir to Unicode in the version that comes with Python 2.3. ---------------------------------------------------------------------- Comment By: Michael Peternell (mpeti) Date: 2003-07-20 18:03 Message: Logged In: YES user_id=809932 Hi lemburg, no, I haven't. It seems the problem only exists on Windows. I am using Windows XP. Look at this URL: http://www.python.org/doc/current/tut/node5.html (Chapter 3.1.3): "...The default encoding is normally set to ASCII, which passes through characters in the range 0 to 127 and rejects any other characters with an error. ..." But they are writing strings in the form u"blabla". Maybe Windows converts everything to Unicode automatically? But thank you anyways. The problem only exists with 2.2.3 and only with Idle. The Dos-Version (python.exe) works proplerly. I've downloaded python 2.3c1 now and everything works fine. But it isn't perfect anyways... >>> x = "Österreich" >>> x '\xd6sterreich' >>> print x Österreich >>> "ññ" '\xf1\xf1' '\xd6' doesn't look very nice, but as long as you can print it, it's not a big problem. and it can parse char(0xf1) (or Alt-164, which equals 0xa4) too. Michael ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-07-20 16:15 Message: Logged In: YES user_id=38388 Are you sure about this ? /home/lemburg> python2.2 Python 2.2.3 (#1, Jul 1 2003, 10:54:49) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> c = "Österreich" >>> Same for Python 2.3. Perhaps you have change something in your site.py file ?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774536&group_id=5470 From noreply@sourceforge.net Sun Jul 20 21:23:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 13:23:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22: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=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Nobody/Anonymous (nobody) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Sun Jul 20 21:46:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 13:46:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-772176 ] digraphs on komment lines / xlib Message-ID: Bugs item #772176, was opened at 2003-07-16 05:24 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772176&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Eckersley (daddio_2) Assigned to: Nobody/Anonymous (nobody) Summary: digraphs on komment lines / xlib Initial Comment: Python 2.3 falls over if it encounters non-ascii characters on comment lines. These occur with digraphs and non English names. e.g. This simple program #!/usr/bin/python print 'This program does nothing' # Aber eine Kommentarzeile l�uft nicht! # The " � " causes trouble # This causes Xlib to stop working causes the following output sys:1: DeprecationWarning: Non-ASCII character '\xe4' in file /nglob/g/bat/digraph.py on line 6, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details This program does nothing Some libraries (such as python-xlib 2.2 ) cause this problem. The line parser ought ignore all comment content whether ascii or not. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-07-20 16:46 Message: Logged In: YES user_id=593130 1. Python 2.3 has not been released yet. Please indicate exact versions on bug reports. Including the system and OS often helps too. 2. The reported behavior is intentional and not a bug. See Reference Manual 2. Lexical analysis: "Python uses the 7-bit ASCII character set" and the referenced PEP 0263. Please close this report. 3. If a standard library module were to generate this warning, that would be a bug that should be reported here. If a third-party library does so, get a version updated for 2.3 or request that the authors make one. 4. If you want to discuss intended behavior, post to comp.lang.python. While your request about ignoring comments is superficially reasonable, the PEP seems to indicate that encoding is dealt with, and the warning issued, *before* any actual parsing, which is to say, before the parser knows what is a comment and what is not. Detecting comments is not trivial since '#' within a string does not start a comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772176&group_id=5470 From noreply@sourceforge.net Sun Jul 20 22:10:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 14:10:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Nobody/Anonymous (nobody) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Sun Jul 20 22:12:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 14:12:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-774536 ] UnicodeError Message-ID: Bugs item #774536, was opened at 2003-07-20 13:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774536&group_id=5470 Category: IDLE Group: Python 2.2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Michael Peternell (mpeti) Assigned to: Nobody/Anonymous (nobody) Summary: UnicodeError Initial Comment: >>> c = "Österreich" UnicodeError: ASCII encoding error: ordinal not in range(128) the parser must not consider the German language an error. the same for French: >>> c = "Kate Ryan - Désenchantée" UnicodeError: ASCII encoding error: ordinal not in range(128) I think this behavior was INTENDED, or why did the error message say "ordinal not in range(128)"? This is not an error. It is intended that bytes have 8 bits and not 7. I hope you don't reject this bug. Michael ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:12 Message: Logged In: YES user_id=21627 As Marc-Andre explains, this bug is fixed in Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-07-20 18:17 Message: Logged In: YES user_id=38388 Ah, so it's an IDLE problem, not a Python one. AFAIK, IDLE behaves much better wir to Unicode in the version that comes with Python 2.3. ---------------------------------------------------------------------- Comment By: Michael Peternell (mpeti) Date: 2003-07-20 18:03 Message: Logged In: YES user_id=809932 Hi lemburg, no, I haven't. It seems the problem only exists on Windows. I am using Windows XP. Look at this URL: http://www.python.org/doc/current/tut/node5.html (Chapter 3.1.3): "...The default encoding is normally set to ASCII, which passes through characters in the range 0 to 127 and rejects any other characters with an error. ..." But they are writing strings in the form u"blabla". Maybe Windows converts everything to Unicode automatically? But thank you anyways. The problem only exists with 2.2.3 and only with Idle. The Dos-Version (python.exe) works proplerly. I've downloaded python 2.3c1 now and everything works fine. But it isn't perfect anyways... >>> x = "Österreich" >>> x '\xd6sterreich' >>> print x Österreich >>> "ññ" '\xf1\xf1' '\xd6' doesn't look very nice, but as long as you can print it, it's not a big problem. and it can parse char(0xf1) (or Alt-164, which equals 0xa4) too. Michael ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-07-20 16:15 Message: Logged In: YES user_id=38388 Are you sure about this ? /home/lemburg> python2.2 Python 2.2.3 (#1, Jul 1 2003, 10:54:49) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> c = "Österreich" >>> Same for Python 2.3. Perhaps you have change something in your site.py file ?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774536&group_id=5470 From noreply@sourceforge.net Sun Jul 20 22:14:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 14:14:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-774480 ] 2.3c1 readme unparseable sentence Message-ID: Bugs item #774480, was opened at 2003-07-20 09:24 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774480&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neil T. Spring (bluehal) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3c1 readme unparseable sentence Initial Comment: In the section "Building a shared libpython": "In particular, the library likely object files using position-independent code (PIC) if PIC flags are needed for the shared library." I expect something goes between "likely" and "object," but I don't know what it might be. My guess (without actually knowing how it works) is that the paragraph should read: If you enable this feature, the same object files will be used to create a static library as well from the same object files. Note that these objects will consist of position-independent code (PIC) on platforms where PIC flags are needed for the shared library. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:14 Message: Logged In: YES user_id=21627 Would the sentence be correct if the world "contains" is added between "likely" and "object"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774480&group_id=5470 From noreply@sourceforge.net Sun Jul 20 22:59:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 14:59:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-774536 ] UnicodeError Message-ID: Bugs item #774536, was opened at 2003-07-20 07:59 Message generated for change (Comment added) made by tjreedy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774536&group_id=5470 Category: IDLE Group: Python 2.2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Peternell (mpeti) Assigned to: Nobody/Anonymous (nobody) Summary: UnicodeError Initial Comment: >>> c = "Österreich" UnicodeError: ASCII encoding error: ordinal not in range(128) the parser must not consider the German language an error. the same for French: >>> c = "Kate Ryan - Désenchantée" UnicodeError: ASCII encoding error: ordinal not in range(128) I think this behavior was INTENDED, or why did the error message say "ordinal not in range(128)"? This is not an error. It is intended that bytes have 8 bits and not 7. I hope you don't reject this bug. Michael ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-07-20 17:59 Message: Logged In: YES user_id=593130 The difference between '>>> x' printing repr(x) and '>>> print x' printing str(x) is, I believe, intended. Unless you can identify an actual bug in 2.2.3 or 2.3rc1 or later + new Idle, please close this. The open bug list is already too long (at 370+). In the future, including version, system, and IDE (if applicable) in the original report would usually be helpful. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 17:12 Message: Logged In: YES user_id=21627 As Marc-Andre explains, this bug is fixed in Python 2.3. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-07-20 12:17 Message: Logged In: YES user_id=38388 Ah, so it's an IDLE problem, not a Python one. AFAIK, IDLE behaves much better wir to Unicode in the version that comes with Python 2.3. ---------------------------------------------------------------------- Comment By: Michael Peternell (mpeti) Date: 2003-07-20 12:03 Message: Logged In: YES user_id=809932 Hi lemburg, no, I haven't. It seems the problem only exists on Windows. I am using Windows XP. Look at this URL: http://www.python.org/doc/current/tut/node5.html (Chapter 3.1.3): "...The default encoding is normally set to ASCII, which passes through characters in the range 0 to 127 and rejects any other characters with an error. ..." But they are writing strings in the form u"blabla". Maybe Windows converts everything to Unicode automatically? But thank you anyways. The problem only exists with 2.2.3 and only with Idle. The Dos-Version (python.exe) works proplerly. I've downloaded python 2.3c1 now and everything works fine. But it isn't perfect anyways... >>> x = "Österreich" >>> x '\xd6sterreich' >>> print x Österreich >>> "ññ" '\xf1\xf1' '\xd6' doesn't look very nice, but as long as you can print it, it's not a big problem. and it can parse char(0xf1) (or Alt-164, which equals 0xa4) too. Michael ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2003-07-20 10:15 Message: Logged In: YES user_id=38388 Are you sure about this ? /home/lemburg> python2.2 Python 2.2.3 (#1, Jul 1 2003, 10:54:49) [GCC 2.95.3 20010315 (SuSE)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> c = "Österreich" >>> Same for Python 2.3. Perhaps you have change something in your site.py file ?! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774536&group_id=5470 From noreply@sourceforge.net Sun Jul 20 23:38:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 15:38:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-774188 ] XP manifest files should be installed Message-ID: Bugs item #774188, was opened at 2003-07-19 09: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=774188&group_id=5470 Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Henk Punt (h_punt) Assigned to: Mark Hammond (mhammond) Summary: XP manifest files should be installed Initial Comment: In order for python based windows programs to use the right widget (e.g. common control) versions on XP, a manifest file must be present for both executables (python.exe and pythonw.exe). I believe Python2.2 installs these per default. If these are not present, weird graphical artifacts may show up on windows XP in tree and list controls when high-color icons are used. A sample of a manifest file ('pythonw.exe.manifest'): Python Interpreter ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-20 18:38 Message: Logged In: YES user_id=31435 I'm closing this, for lack of a sane way to proceed at this time. The http://www.python.org/cgi-bin/moinmoin/PythonQuestions link has a claim that adding a manifest file caused Tkinter to crash ... until it's clear what to do, I'm not touching this. ---------------------------------------------------------------------- Comment By: Henk Punt (h_punt) Date: 2003-07-20 04:36 Message: Logged In: YES user_id=729698 I've googled around a bit more, http://www.python.org/cgi-bin/moinmoin/PythonQuestions section '4 Windows XP look-and-feel' advises against it, apparently somebody ran into problems with this. Mark is right, we don't know what the right control library is for any program run with the python.exe interpreter. sigh, I guess for microsoft a program is only a program when it is an .exe :-(. As far as I am concerned this is also not very critical. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-20 00:40 Message: Logged In: YES user_id=14198 Welcome to .NET . I can believe this would help some GUI programs, but am hard pressed to call it critical enough to bang in 2.3 at this late stage. A concern is that how do we know the assertion about what control library we want to use is true for *all* programs hosted by our executables? ---------------------------------------------------------------------- Comment By: Henk Punt (h_punt) Date: 2003-07-19 18:25 Message: Logged In: YES user_id=729698 I may have put them there myself, It is a known problem though, lookup section '2.4.2.1 Windows XP and Python 2.2.2' of the wxpython Wiki at: http://wiki.wxpython.org/index.cgi/Frequently_20Asked_20Que stions It would not hurt to have these installed by default for the Windows platform ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-19 16:15 Message: Logged In: YES user_id=31435 Mark, does this mean anything to you? We've (PLabs) certainly never installed anything like this before. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774188&group_id=5470 From noreply@sourceforge.net Sun Jul 20 23:47:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 15:47:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22:23 Message generated for change (Comment added) made by barto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Nobody/Anonymous (nobody) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 00:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Sun Jul 20 23:51:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 15:51:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 15:23 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Bartolomé Sintes Marco (barto) >Assigned to: Kurt B. Kaiser (kbk) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-20 17:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-20 17:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 16:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Mon Jul 21 00:03:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 16:03:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-774546 ] popen does not like filenames with spaces Message-ID: Bugs item #774546, was opened at 2003-07-20 07:29 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774546&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: popen does not like filenames with spaces Initial Comment: The argument for the target executable are passed as a string to popen. The problem is that with filenames which contains spaces, the argument breaking routine will fail and create two arguments for one filename. It would be more convenient if one could pass the argument to popen as a list of string. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-20 18:03 Message: Logged In: YES user_id=80475 Does it work for you if the filename is quoted: "thrill seeker.txt" ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774546&group_id=5470 From noreply@sourceforge.net Mon Jul 21 00:05:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 16:05:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Kurt B. Kaiser (kbk) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-21 01:05 Message: Logged In: YES user_id=21627 rhettinger: In IDLE 1.0, IDLE should not ever refuse to safe the file, unless the declared encoding (through the coding: declaration) cannot support the characters in the file. barto: I still don't understand what you did, either in case a) or case b). Can you give precise data? For a), please report what specific encoding you have put into sitecustomize.py, what code page your windows installation uses, and please attach a file that you have created with IDLE 0.8. For b), what do you mean by "save does not work"? Was there some error message? If so, what did it say? If not, what else was wrong. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 00:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 00:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Mon Jul 21 00:28:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 16:28:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 15:23 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Kurt B. Kaiser (kbk) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-20 18:28 Message: Logged In: YES user_id=80475 If Bartolomé is having the same issue I had (on Py2.3b2, but disappeared on PY2.3c1), then the symptoms were: Open Doc/tut/tut.tex Make minor edits Observe: - the stars by the filename show a need for a save - the editor window shows the changes Save (using Cntl-S, File Save, or FileSaveAs) Observe: - no windows pop-up refusing to save - the stars remain - the syntax highlighting indicates that no valid python syntax was found Exit IDLE - get prompted to save and say YES - the exit occurs Look at the file - note that the changes did not take For a brief while, I could re-create this reliably. No one else has been able to reproduce (leading me to think this was specific to WinMe). I could also reproduce it on small files and files like "c:\a.tmp" (leading me to think it was independent of o.s. pathnaming conventions). For a while, I could also reproduce it on a fresh build, but that stopped as soon that the last release candidate changes went in. Sorry for the circuituous report, but if I knew what it was, it would be fixed already. Also, since no one else could reproduce it, I was beginning to suspect my own machine. If Bartolomé is having save problems without getting a warning window then, he is having the same issue. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 18:05 Message: Logged In: YES user_id=21627 rhettinger: In IDLE 1.0, IDLE should not ever refuse to safe the file, unless the declared encoding (through the coding: declaration) cannot support the characters in the file. barto: I still don't understand what you did, either in case a) or case b). Can you give precise data? For a), please report what specific encoding you have put into sitecustomize.py, what code page your windows installation uses, and please attach a file that you have created with IDLE 0.8. For b), what do you mean by "save does not work"? Was there some error message? If so, what did it say? If not, what else was wrong. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-20 17:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-20 17:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 16:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Mon Jul 21 00:57:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 16:57:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-774751 ] slow socket binding & netinfo lookups Message-ID: Bugs item #774751, was opened at 2003-07-21 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=774751&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: slow socket binding & netinfo lookups Initial Comment: The following code takes < 1 second to run under Python 2.1, but 20 seconds to run under Python 2.2 or 2.3 on a top- end PowerBook running OSX 10.2. It is part of the Zope startup routine. def max_server_sockets(): sl = [] while 1: try: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) s.listen(5) sl.append (s) except: break num = len(sl) for s in sl: s.close() del sl return num ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 From noreply@sourceforge.net Mon Jul 21 01:37:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 17:37:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-772176 ] digraphs on komment lines / xlib Message-ID: Bugs item #772176, was opened at 2003-07-16 09:24 Message generated for change (Comment added) made by daddio_2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772176&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregory Eckersley (daddio_2) Assigned to: Nobody/Anonymous (nobody) Summary: digraphs on komment lines / xlib Initial Comment: Python 2.3 falls over if it encounters non-ascii characters on comment lines. These occur with digraphs and non English names. e.g. This simple program #!/usr/bin/python print 'This program does nothing' # Aber eine Kommentarzeile l�uft nicht! # The " � " causes trouble # This causes Xlib to stop working causes the following output sys:1: DeprecationWarning: Non-ASCII character '\xe4' in file /nglob/g/bat/digraph.py on line 6, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details This program does nothing Some libraries (such as python-xlib 2.2 ) cause this problem. The line parser ought ignore all comment content whether ascii or not. ---------------------------------------------------------------------- >Comment By: Gregory Eckersley (daddio_2) Date: 2003-07-21 00:37 Message: Logged In: YES user_id=823572 I understand & agree with your comments. I did not include the exact version since it , as you say, seems to be an undesirable (in this case) consequence of the PEP. Please consider this bug report closed, and I'll follow it up in the short term with xlib, and in the longer term with the PEP after looking at whether there is a simple and systematic way of handling this. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2003-07-20 20:46 Message: Logged In: YES user_id=593130 1. Python 2.3 has not been released yet. Please indicate exact versions on bug reports. Including the system and OS often helps too. 2. The reported behavior is intentional and not a bug. See Reference Manual 2. Lexical analysis: "Python uses the 7-bit ASCII character set" and the referenced PEP 0263. Please close this report. 3. If a standard library module were to generate this warning, that would be a bug that should be reported here. If a third-party library does so, get a version updated for 2.3 or request that the authors make one. 4. If you want to discuss intended behavior, post to comp.lang.python. While your request about ignoring comments is superficially reasonable, the PEP seems to indicate that encoding is dealt with, and the warning issued, *before* any actual parsing, which is to say, before the parser knows what is a comment and what is not. Detecting comments is not trivial since '#' within a string does not start a comment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772176&group_id=5470 From noreply@sourceforge.net Mon Jul 21 04:46:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 20 Jul 2003 20:46:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-774798 ] SSL bug in socketmodule.c using threads Message-ID: Bugs item #774798, was opened at 2003-07-21 03: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=774798&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Liraz Siri (zaril) Assigned to: Nobody/Anonymous (nobody) Summary: SSL bug in socketmodule.c using threads Initial Comment: I recently came across a bug in the SSL code in Modules/socketmodule.c. Most of the SSL functions support python threads, but the the constructor function for the SSL session does not. This can hang a multi threaded application if the SSL_connect stalls / hangs / takes a really long time etc. In my application, for example, this prevented me from cancelling an SSL connection to a badly routed destination or a very slow destination, since the GUI hanged. Once I enabled threading support in that function in socketmodule.c, the problem was easily fixed. Is there any reason for the SSL constructor in socketmodule.c to be thread unsafe? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774798&group_id=5470 From noreply@sourceforge.net Mon Jul 21 08:02:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 00:02:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 15:23 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None >Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) >Assigned to: Raymond Hettinger (rhettinger) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 02:02 Message: Logged In: YES user_id=80475 I'll continue to work on this one to see if I can use the debugger to isolate the problem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-20 18:28 Message: Logged In: YES user_id=80475 If Bartolomé is having the same issue I had (on Py2.3b2, but disappeared on PY2.3c1), then the symptoms were: Open Doc/tut/tut.tex Make minor edits Observe: - the stars by the filename show a need for a save - the editor window shows the changes Save (using Cntl-S, File Save, or FileSaveAs) Observe: - no windows pop-up refusing to save - the stars remain - the syntax highlighting indicates that no valid python syntax was found Exit IDLE - get prompted to save and say YES - the exit occurs Look at the file - note that the changes did not take For a brief while, I could re-create this reliably. No one else has been able to reproduce (leading me to think this was specific to WinMe). I could also reproduce it on small files and files like "c:\a.tmp" (leading me to think it was independent of o.s. pathnaming conventions). For a while, I could also reproduce it on a fresh build, but that stopped as soon that the last release candidate changes went in. Sorry for the circuituous report, but if I knew what it was, it would be fixed already. Also, since no one else could reproduce it, I was beginning to suspect my own machine. If Bartolomé is having save problems without getting a warning window then, he is having the same issue. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 18:05 Message: Logged In: YES user_id=21627 rhettinger: In IDLE 1.0, IDLE should not ever refuse to safe the file, unless the declared encoding (through the coding: declaration) cannot support the characters in the file. barto: I still don't understand what you did, either in case a) or case b). Can you give precise data? For a), please report what specific encoding you have put into sitecustomize.py, what code page your windows installation uses, and please attach a file that you have created with IDLE 0.8. For b), what do you mean by "save does not work"? Was there some error message? If so, what did it say? If not, what else was wrong. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-20 17:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-20 17:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 16:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Mon Jul 21 08:05:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 00:05:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-774751 ] slow socket binding & netinfo lookups Message-ID: Bugs item #774751, was opened at 2003-07-21 09:57 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: slow socket binding & netinfo lookups Initial Comment: The following code takes < 1 second to run under Python 2.1, but 20 seconds to run under Python 2.2 or 2.3 on a top- end PowerBook running OSX 10.2. It is part of the Zope startup routine. def max_server_sockets(): sl = [] while 1: try: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) s.listen(5) sl.append (s) except: break num = len(sl) for s in sl: s.close() del sl return num ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-21 17:05 Message: Logged In: YES user_id=29957 Is this something that should be looked at for 2.3rc2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 From noreply@sourceforge.net Mon Jul 21 08:27:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 00:27:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-774846 ] test_descr fails from IDLE Message-ID: Bugs item #774846, was opened at 2003-07-21 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=774846&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_descr fails from IDLE Initial Comment: Hello, When running test_descr from IDLE it fails. Running from command line is OK. Attached are outputs from IDLE and command line. Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774846&group_id=5470 From noreply@sourceforge.net Mon Jul 21 08:32:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 00:32:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-768306 ] Distutils broken on Os X Message-ID: Bugs item #768306, was opened at 2003-07-09 11:28 Message generated for change (Comment added) made by torstenrueger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768306&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Torsten Rueger (torstenrueger) Assigned to: Jack Jansen (jackjansen) Summary: Distutils broken on Os X Initial Comment: Os X 10.2.6. Python 2.3b2 from http://homepages.cwi.nl/~jack/ macpython.html#beta Trying to comiple py-xml-rpc 2.8.3 from http:// sourceforge.net/projects/py-xmlrpc/ I get a ton of multiple defined symbols like: ld: multiple definitions of symbol _rpcBase64Type build/temp.darwin-6.6-Power_Macintosh-2.3/src/rpcBase64.o definition of _rpcBase64Type in section (__DATA,__data) build/temp.darwin-6.6-Power_Macintosh-2.3/src/ rpcBoolean.o definition of _rpcBase64Type in section (__DATA,__common) ld: multiple definitions of symbol _rpcBoolType ..... I tracked this down to the presence of the compile flag "- fno-common" used by the distutils. The man page for gcc states quite clearly that this is not usually an advisable flag, quote: -fno-common In C, allocate even uninitialized global variables in the data section of the object file, rather than gen- erating them as common blocks. This has the effect that if the same variable is declared (without "extern") in two different compilations, you will get an error when you link them. The only reason this might be useful is if you wish to verify that the pro- gram will work on other systems which always work this way. I have compiled and linked all files with the makefile that is also distributed in py-xmlrpc, but I had to change the link options to "-flat_namespace -undefined warning". I can help in testing a fix if someone can assist with distutils knowledge. Torsten ---------------------------------------------------------------------- >Comment By: Torsten Rueger (torstenrueger) Date: 2003-07-21 10:32 Message: Logged In: YES user_id=651431 Yes, my Python is a framework built, as seems to be neccessary to run wxWindows. So that stops it working it seems. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-20 05:16 Message: Logged In: YES user_id=44345 Works for me (python setup.py install ; python -c 'import xmlrpc'). I don't see -fnocommon in the gcc flags. This is with a Unix-style build of Python, not a framework build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768306&group_id=5470 From noreply@sourceforge.net Mon Jul 21 08:34:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 00:34:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-772787 ] right button context 'edit with idle' Message-ID: Bugs item #772787, was opened at 2003-07-17 07:36 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: nestor (nestor5) Assigned to: Nobody/Anonymous (nobody) Summary: right button context 'edit with idle' Initial Comment: after installing Python 2.3b2 under windows, the right mouse button context option in windows explorer 'edit with idle' on *.py files ceased to work on two mashines (I upgraded from python b1 to b2). One was Windows 2000 and one was Windows XP. Installation is default C:\python23 installation. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 10:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 From noreply@sourceforge.net Mon Jul 21 08:34:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 00:34:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-772787 ] right button context 'edit with idle' Message-ID: Bugs item #772787, was opened at 2003-07-17 07:36 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: nestor (nestor5) Assigned to: Nobody/Anonymous (nobody) Summary: right button context 'edit with idle' Initial Comment: after installing Python 2.3b2 under windows, the right mouse button context option in windows explorer 'edit with idle' on *.py files ceased to work on two mashines (I upgraded from python b1 to b2). One was Windows 2000 and one was Windows XP. Installation is default C:\python23 installation. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 10:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 10:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 From noreply@sourceforge.net Mon Jul 21 14:20:54 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 06:20:54 -0700 Subject: [Python-bugs-list] [ python-Bugs-762855 ] ioctl only accepts 1024 byte arguments Message-ID: Bugs item #762855, was opened at 2003-06-29 21:29 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762855&group_id=5470 Category: Python Library Group: Platform-specific >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Robert Penz (robertpenz) >Assigned to: Michael Hudson (mwh) Summary: ioctl only accepts 1024 byte arguments Initial Comment: Hi! The buffer in /python/dist/src/Modules/fcntlmodule.c ist hardcoded to 1024 byte. It would be cool if would be dynamic allocated or at least make it 10k big. my argnument has an size of 1816 byte char buf[1024]; ..... if (len > sizeof buf) { PyErr_SetString(PyExc_ValueError, "ioctl string arg too long"); return NULL; ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-07-21 14:20 Message: Logged In: YES user_id=6656 Python 2.3 already does something like this. You have to pass in an array.array (or other writable buffer). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=762855&group_id=5470 From noreply@sourceforge.net Mon Jul 21 14:35:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 06:35:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-775012 ] No syntax hilite on new file until saved as *.py Message-ID: Bugs item #775012, was opened at 2003-07-21 14:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775012&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andy Jewell (cybervegan) Assigned to: Nobody/Anonymous (nobody) Summary: No syntax hilite on new file until saved as *.py Initial Comment: python 2.3c1, on windows xp, uk english. When typing or pasting into a new text window, no syntax highlighting appears until the file is saved with a .py name. I know it doesn't make sense to python-syntax highlight a non-python file, but shouldn't it default to highlighting? IDLE never used to do this - I assume it's a quirk of IDLEfork (maybe intentional behaviour i suppose). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775012&group_id=5470 From noreply@sourceforge.net Mon Jul 21 14:41:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 06:41:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-774798 ] SSL bug in socketmodule.c using threads Message-ID: Bugs item #774798, was opened at 2003-07-20 23:46 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774798&group_id=5470 Category: Extension Modules Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Liraz Siri (zaril) Assigned to: Nobody/Anonymous (nobody) Summary: SSL bug in socketmodule.c using threads Initial Comment: I recently came across a bug in the SSL code in Modules/socketmodule.c. Most of the SSL functions support python threads, but the the constructor function for the SSL session does not. This can hang a multi threaded application if the SSL_connect stalls / hangs / takes a really long time etc. In my application, for example, this prevented me from cancelling an SSL connection to a badly routed destination or a very slow destination, since the GUI hanged. Once I enabled threading support in that function in socketmodule.c, the problem was easily fixed. Is there any reason for the SSL constructor in socketmodule.c to be thread unsafe? ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-21 09:41 Message: Logged In: YES user_id=33168 Please attach the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774798&group_id=5470 From noreply@sourceforge.net Mon Jul 21 14:43:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 06:43:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-775012 ] No syntax hilite on new file until saved as *.py Message-ID: Bugs item #775012, was opened at 2003-07-21 09:35 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775012&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andy Jewell (cybervegan) >Assigned to: Kurt B. Kaiser (kbk) Summary: No syntax hilite on new file until saved as *.py Initial Comment: python 2.3c1, on windows xp, uk english. When typing or pasting into a new text window, no syntax highlighting appears until the file is saved with a .py name. I know it doesn't make sense to python-syntax highlight a non-python file, but shouldn't it default to highlighting? IDLE never used to do this - I assume it's a quirk of IDLEfork (maybe intentional behaviour i suppose). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775012&group_id=5470 From noreply@sourceforge.net Mon Jul 21 15:10:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 07:10:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22:23 Message generated for change (Comment added) made by barto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Raymond Hettinger (rhettinger) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:10 Message: Logged In: YES user_id=624347 Let's start from the beginning: 1. I uninstall Python from my system (Windows 98 SE Spanish) In my autoexec.bat I can read mode con codepage prepare=((850)C:\WINDOWS\COMMAND\ega.cpi) mode con codepage select=850 keyb sp,,C:\WINDOWS\COMMAND\keyboard.sys 2. I install Python 2.2.3 3. I open IDLE 0.8 4. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 5. If I try to save this file as test01.py, I get the following IDLE message Exception in Tkinter callback Traceback (most recent call last): File "C:\ARCHIVOS DE PROGRAMA\PYTHON223\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 126, in save self.save_as(event) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 136, in save_as if self.writefile(filename): File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 151, in writefile chars = str(self.text.get("1.0", "end-1c")) UnicodeError: ASCII encoding error: ordinal not in range(128) 6. I add the following sitecustomize.py file to lib/site-packages: # Set the string encoding used by the Unicode implementation. # The default is 'ascii' encoding = "ascii" # <= CHANGE THIS if you wish # Enable to support locale aware default string encodings. import locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1] print encoding if encoding != "ascii": import sys sys.setdefaultencoding(encoding) 7. I close IDLE 0.8 (without saving test01.py) 8. I open again IDLE 0.8 9. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 10. I save the file as test01.py (no messages, no warnings) 11. I close IDLE 0.8 12. I open IDLE 0.8. I load test01.py and run it. Everything is OK. 13. I uninstall Python 2.2.3 and install Python 2.3rc1 14. I open IDLE 1.0rc1 and open test01.py. That is what I see print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters => I think this behaviour can be an IDLE bug. 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. 16 I delete non-ASCII characters. The program is now: print "hola, mundo!" print 17. I save it as test02.py without problems. 18. I close test02.py and open it again. I add non ASCII characters. The program is now: print "¡hola, mundo!" print "áéíóú" 19. I try to save it as test03.py. IDLE shows me the warning message "Non-ASCII found, yet no encoding declared". I click in "Edit my file". The program is now: # -*- coding: cp1252 -*- print "¡hola, mundo!" print "áéíóú" I try to save it again as test03.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test02.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. I am sending attached the test01.py file. By the way, IDLE creates a .idlerc folder (with a recent-files.lst file in it) in the folder where I have created test02.py file. Is it normal? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 09:02 Message: Logged In: YES user_id=80475 I'll continue to work on this one to see if I can use the debugger to isolate the problem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 01:28 Message: Logged In: YES user_id=80475 If Bartolomé is having the same issue I had (on Py2.3b2, but disappeared on PY2.3c1), then the symptoms were: Open Doc/tut/tut.tex Make minor edits Observe: - the stars by the filename show a need for a save - the editor window shows the changes Save (using Cntl-S, File Save, or FileSaveAs) Observe: - no windows pop-up refusing to save - the stars remain - the syntax highlighting indicates that no valid python syntax was found Exit IDLE - get prompted to save and say YES - the exit occurs Look at the file - note that the changes did not take For a brief while, I could re-create this reliably. No one else has been able to reproduce (leading me to think this was specific to WinMe). I could also reproduce it on small files and files like "c:\a.tmp" (leading me to think it was independent of o.s. pathnaming conventions). For a while, I could also reproduce it on a fresh build, but that stopped as soon that the last release candidate changes went in. Sorry for the circuituous report, but if I knew what it was, it would be fixed already. Also, since no one else could reproduce it, I was beginning to suspect my own machine. If Bartolomé is having save problems without getting a warning window then, he is having the same issue. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-21 01:05 Message: Logged In: YES user_id=21627 rhettinger: In IDLE 1.0, IDLE should not ever refuse to safe the file, unless the declared encoding (through the coding: declaration) cannot support the characters in the file. barto: I still don't understand what you did, either in case a) or case b). Can you give precise data? For a), please report what specific encoding you have put into sitecustomize.py, what code page your windows installation uses, and please attach a file that you have created with IDLE 0.8. For b), what do you mean by "save does not work"? Was there some error message? If so, what did it say? If not, what else was wrong. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 00:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 00:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Mon Jul 21 15:16:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 07:16:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22:23 Message generated for change (Comment added) made by barto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Raymond Hettinger (rhettinger) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:15 Message: Logged In: YES user_id=624347 Sorry, but there is at least a mistake in my previous message. Item 15 should be: 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py) => I think this behaviour can be an IDLE bug, too. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:10 Message: Logged In: YES user_id=624347 Let's start from the beginning: 1. I uninstall Python from my system (Windows 98 SE Spanish) In my autoexec.bat I can read mode con codepage prepare=((850)C:\WINDOWS\COMMAND\ega.cpi) mode con codepage select=850 keyb sp,,C:\WINDOWS\COMMAND\keyboard.sys 2. I install Python 2.2.3 3. I open IDLE 0.8 4. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 5. If I try to save this file as test01.py, I get the following IDLE message Exception in Tkinter callback Traceback (most recent call last): File "C:\ARCHIVOS DE PROGRAMA\PYTHON223\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 126, in save self.save_as(event) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 136, in save_as if self.writefile(filename): File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 151, in writefile chars = str(self.text.get("1.0", "end-1c")) UnicodeError: ASCII encoding error: ordinal not in range(128) 6. I add the following sitecustomize.py file to lib/site-packages: # Set the string encoding used by the Unicode implementation. # The default is 'ascii' encoding = "ascii" # <= CHANGE THIS if you wish # Enable to support locale aware default string encodings. import locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1] print encoding if encoding != "ascii": import sys sys.setdefaultencoding(encoding) 7. I close IDLE 0.8 (without saving test01.py) 8. I open again IDLE 0.8 9. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 10. I save the file as test01.py (no messages, no warnings) 11. I close IDLE 0.8 12. I open IDLE 0.8. I load test01.py and run it. Everything is OK. 13. I uninstall Python 2.2.3 and install Python 2.3rc1 14. I open IDLE 1.0rc1 and open test01.py. That is what I see print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters => I think this behaviour can be an IDLE bug. 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. 16 I delete non-ASCII characters. The program is now: print "hola, mundo!" print 17. I save it as test02.py without problems. 18. I close test02.py and open it again. I add non ASCII characters. The program is now: print "¡hola, mundo!" print "áéíóú" 19. I try to save it as test03.py. IDLE shows me the warning message "Non-ASCII found, yet no encoding declared". I click in "Edit my file". The program is now: # -*- coding: cp1252 -*- print "¡hola, mundo!" print "áéíóú" I try to save it again as test03.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test02.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. I am sending attached the test01.py file. By the way, IDLE creates a .idlerc folder (with a recent-files.lst file in it) in the folder where I have created test02.py file. Is it normal? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 09:02 Message: Logged In: YES user_id=80475 I'll continue to work on this one to see if I can use the debugger to isolate the problem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 01:28 Message: Logged In: YES user_id=80475 If Bartolomé is having the same issue I had (on Py2.3b2, but disappeared on PY2.3c1), then the symptoms were: Open Doc/tut/tut.tex Make minor edits Observe: - the stars by the filename show a need for a save - the editor window shows the changes Save (using Cntl-S, File Save, or FileSaveAs) Observe: - no windows pop-up refusing to save - the stars remain - the syntax highlighting indicates that no valid python syntax was found Exit IDLE - get prompted to save and say YES - the exit occurs Look at the file - note that the changes did not take For a brief while, I could re-create this reliably. No one else has been able to reproduce (leading me to think this was specific to WinMe). I could also reproduce it on small files and files like "c:\a.tmp" (leading me to think it was independent of o.s. pathnaming conventions). For a while, I could also reproduce it on a fresh build, but that stopped as soon that the last release candidate changes went in. Sorry for the circuituous report, but if I knew what it was, it would be fixed already. Also, since no one else could reproduce it, I was beginning to suspect my own machine. If Bartolomé is having save problems without getting a warning window then, he is having the same issue. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-21 01:05 Message: Logged In: YES user_id=21627 rhettinger: In IDLE 1.0, IDLE should not ever refuse to safe the file, unless the declared encoding (through the coding: declaration) cannot support the characters in the file. barto: I still don't understand what you did, either in case a) or case b). Can you give precise data? For a), please report what specific encoding you have put into sitecustomize.py, what code page your windows installation uses, and please attach a file that you have created with IDLE 0.8. For b), what do you mean by "save does not work"? Was there some error message? If so, what did it say? If not, what else was wrong. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 00:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 00:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Mon Jul 21 15:48:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 07:48:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-768306 ] Distutils broken on Os X Message-ID: Bugs item #768306, was opened at 2003-07-09 10:28 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768306&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Torsten Rueger (torstenrueger) Assigned to: Jack Jansen (jackjansen) Summary: Distutils broken on Os X Initial Comment: Os X 10.2.6. Python 2.3b2 from http://homepages.cwi.nl/~jack/ macpython.html#beta Trying to comiple py-xml-rpc 2.8.3 from http:// sourceforge.net/projects/py-xmlrpc/ I get a ton of multiple defined symbols like: ld: multiple definitions of symbol _rpcBase64Type build/temp.darwin-6.6-Power_Macintosh-2.3/src/rpcBase64.o definition of _rpcBase64Type in section (__DATA,__data) build/temp.darwin-6.6-Power_Macintosh-2.3/src/ rpcBoolean.o definition of _rpcBase64Type in section (__DATA,__common) ld: multiple definitions of symbol _rpcBoolType ..... I tracked this down to the presence of the compile flag "- fno-common" used by the distutils. The man page for gcc states quite clearly that this is not usually an advisable flag, quote: -fno-common In C, allocate even uninitialized global variables in the data section of the object file, rather than gen- erating them as common blocks. This has the effect that if the same variable is declared (without "extern") in two different compilations, you will get an error when you link them. The only reason this might be useful is if you wish to verify that the pro- gram will work on other systems which always work this way. I have compiled and linked all files with the makefile that is also distributed in py-xmlrpc, but I had to change the link options to "-flat_namespace -undefined warning". I can help in testing a fix if someone can assist with distutils knowledge. Torsten ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 16:48 Message: Logged In: YES user_id=45365 While I don't remember why the -fno-common is there in the first place I don't dare to take it out before 2.3: the fact that the framework build has it while the normal build doesn't have it suggests that there is a good reason for it. And I think that having a 2.3 framework built with -fno-common means that it can't even go out for 2.3.X, although I'm not 100% sure about that one (-fno-common definitely can't be added at a micro-release). But: I cant imagine that this can't be fixed at the pyxml side of things. Unix is the only platform I know that has this "common" idea, on old-Mac and Windows you always have to put "extern" in front of every declaration but one. So pyxml probably has a compile time define that adds the necessary magic. ---------------------------------------------------------------------- Comment By: Torsten Rueger (torstenrueger) Date: 2003-07-21 09:32 Message: Logged In: YES user_id=651431 Yes, my Python is a framework built, as seems to be neccessary to run wxWindows. So that stops it working it seems. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-20 04:16 Message: Logged In: YES user_id=44345 Works for me (python setup.py install ; python -c 'import xmlrpc'). I don't see -fnocommon in the gcc flags. This is with a Unix-style build of Python, not a framework build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768306&group_id=5470 From noreply@sourceforge.net Mon Jul 21 15:56:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 07:56:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-773450 ] 2.3b2 pimp.py calls non-existent routine Message-ID: Bugs item #773450, was opened at 2003-07-18 07:59 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773450&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open >Resolution: Fixed Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Jack Jansen (jackjansen) Summary: 2.3b2 pimp.py calls non-existent routine Initial Comment: On line 589, there is a call to _fmtpackagename(self). No such routine is there, nor is there anything in the distribution that contains the string packagename, in any case, that looks suitable. This is in the 2.3b2 distribution. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 16:56 Message: Logged In: YES user_id=45365 Fixed in pimp.py rev. 1.26.4.1 on the r23c1-branch. The fix will be backported to the main branch later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773450&group_id=5470 From noreply@sourceforge.net Mon Jul 21 16:08:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 08:08:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-775061 ] 2 problems with IDLE Message-ID: Bugs item #775061, was opened at 2003-07-21 11: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=775061&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Kurt B. Kaiser (kbk) Summary: 2 problems with IDLE Initial Comment: Lib/idlelib/idle.py should use #!/usr/bin/env python not /usr/bin/python so the user can modify their path to execute the correct version of python. In Lib/idlelib/rpc.py around line 623, svr.register (svr is an RPCServer instance) is called, but there is no register method AFAICT. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775061&group_id=5470 From noreply@sourceforge.net Mon Jul 21 16:36:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 08:36:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-772787 ] right button context 'edit with idle' Message-ID: Bugs item #772787, was opened at 2003-07-17 00:36 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: nestor (nestor5) Assigned to: Nobody/Anonymous (nobody) Summary: right button context 'edit with idle' Initial Comment: after installing Python 2.3b2 under windows, the right mouse button context option in windows explorer 'edit with idle' on *.py files ceased to work on two mashines (I upgraded from python b1 to b2). One was Windows 2000 and one was Windows XP. Installation is default C:\python23 installation. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-21 11:36 Message: Logged In: YES user_id=31435 On Win2K I can't reproduce tebeka's problem with the instructions as given. But I get a frozen window if I repeat the last two steps. o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" o Right click on another .py file o Choose "Edit with IDLE" ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 03:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 03:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 From noreply@sourceforge.net Mon Jul 21 16:44:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 08:44:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-774846 ] test_descr fails from IDLE Message-ID: Bugs item #774846, was opened at 2003-07-21 03:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774846&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Tim Peters (tim_one) Summary: test_descr fails from IDLE Initial Comment: Hello, When running test_descr from IDLE it fails. Running from command line is OK. Attached are outputs from IDLE and command line. Miki ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-21 11:44 Message: Logged In: YES user_id=31435 The test suite isn't intended to be run from IDLE. There should be lots of problems if you try (including, perhaps, hangs or crashes if you run tests that spawn threads). The intended way to run the test suite on Windows is via python lib/test/regrtest.py from a DOS box, optionally passing the largefile, network, and/or bsddb resource names via the -u switch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774846&group_id=5470 From noreply@sourceforge.net Mon Jul 21 16:47:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 08:47:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-538961 ] Using the lib index mechanically Message-ID: Bugs item #538961, was opened at 2002-04-03 17:02 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538961&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Using the lib index mechanically Initial Comment: If the HTML version of the index to the library documentation (http://www.python.org/doc/current/lib/genindex.html in the online version) would contain anchors at the first entry for the word "foo" in the index this would allow a really nice feature in the IDE (and IDLE, and other ide's): a command "lookup in documentation" that takes the current selection and sends your webbrowser to genindex.html#foo. Or is there already another way to do this? An alternative (more work, but would allow more features) would be to dump the information that is in the index in an XML file. During the index generation process there's probably more interesting info available too. And it would allow to search the indexes of multiple docsets at once (library, refmanual, etc). I'm posting this as a feature request because I haven't even the beginning of an idea how to implement this (in all those years I haven't even succeeded in _building_ the documentation:-). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-21 11:47 Message: Logged In: YES user_id=3066 The Python 2.4 documentation will provide an XML version of the index data. The specific information which can be captured and the way it's expressed remain to be determined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538961&group_id=5470 From noreply@sourceforge.net Mon Jul 21 16:50:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 08:50:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-774751 ] slow socket binding & netinfo lookups Message-ID: Bugs item #774751, was opened at 2003-07-20 19:57 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: slow socket binding & netinfo lookups Initial Comment: The following code takes < 1 second to run under Python 2.1, but 20 seconds to run under Python 2.2 or 2.3 on a top- end PowerBook running OSX 10.2. It is part of the Zope startup routine. def max_server_sockets(): sl = [] while 1: try: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) s.listen(5) sl.append (s) except: break num = len(sl) for s in sl: s.close() del sl return num ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-21 11:50 Message: Logged In: YES user_id=31435 Attaching copious info from Skip Montanaro (skip.txt). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-21 03:05 Message: Logged In: YES user_id=29957 Is this something that should be looked at for 2.3rc2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 From noreply@sourceforge.net Mon Jul 21 16:50:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 08:50:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-538961 ] Using the lib index mechanically Message-ID: Bugs item #538961, was opened at 2002-04-03 17:02 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538961&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Using the lib index mechanically Initial Comment: If the HTML version of the index to the library documentation (http://www.python.org/doc/current/lib/genindex.html in the online version) would contain anchors at the first entry for the word "foo" in the index this would allow a really nice feature in the IDE (and IDLE, and other ide's): a command "lookup in documentation" that takes the current selection and sends your webbrowser to genindex.html#foo. Or is there already another way to do this? An alternative (more work, but would allow more features) would be to dump the information that is in the index in an XML file. During the index generation process there's probably more interesting info available too. And it would allow to search the indexes of multiple docsets at once (library, refmanual, etc). I'm posting this as a feature request because I haven't even the beginning of an idea how to implement this (in all those years I haven't even succeeded in _building_ the documentation:-). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-21 11:50 Message: Logged In: YES user_id=3066 I'll also note that once we have a process for generating the XML version of the index data, it's likely that we can apply it to older versions of the documentation to make them similarly useful. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-21 11:47 Message: Logged In: YES user_id=3066 The Python 2.4 documentation will provide an XML version of the index data. The specific information which can be captured and the way it's expressed remain to be determined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538961&group_id=5470 From noreply@sourceforge.net Mon Jul 21 16:57:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 08:57:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-538961 ] Using the lib index mechanically Message-ID: Bugs item #538961, was opened at 2002-04-04 00:02 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538961&group_id=5470 Category: Documentation Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Using the lib index mechanically Initial Comment: If the HTML version of the index to the library documentation (http://www.python.org/doc/current/lib/genindex.html in the online version) would contain anchors at the first entry for the word "foo" in the index this would allow a really nice feature in the IDE (and IDLE, and other ide's): a command "lookup in documentation" that takes the current selection and sends your webbrowser to genindex.html#foo. Or is there already another way to do this? An alternative (more work, but would allow more features) would be to dump the information that is in the index in an XML file. During the index generation process there's probably more interesting info available too. And it would allow to search the indexes of multiple docsets at once (library, refmanual, etc). I'm posting this as a feature request because I haven't even the beginning of an idea how to implement this (in all those years I haven't even succeeded in _building_ the documentation:-). ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-07-21 17:57 Message: Logged In: YES user_id=11105 At least there's this, and I've got my Xemacs to call it when I press F5: http://starship.python.net/crew/theller/pyhelp.cgi ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-21 17:50 Message: Logged In: YES user_id=3066 I'll also note that once we have a process for generating the XML version of the index data, it's likely that we can apply it to older versions of the documentation to make them similarly useful. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-21 17:47 Message: Logged In: YES user_id=3066 The Python 2.4 documentation will provide an XML version of the index data. The specific information which can be captured and the way it's expressed remain to be determined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=538961&group_id=5470 From noreply@sourceforge.net Mon Jul 21 17:03:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 09:03:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-774480 ] 2.3c1 readme unparseable sentence Message-ID: Bugs item #774480, was opened at 2003-07-20 03:24 Message generated for change (Settings changed) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774480&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Neil T. Spring (bluehal) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: 2.3c1 readme unparseable sentence Initial Comment: In the section "Building a shared libpython": "In particular, the library likely object files using position-independent code (PIC) if PIC flags are needed for the shared library." I expect something goes between "likely" and "object," but I don't know what it might be. My guess (without actually knowing how it works) is that the paragraph should read: If you enable this feature, the same object files will be used to create a static library as well from the same object files. Note that these objects will consist of position-independent code (PIC) on platforms where PIC flags are needed for the shared library. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-21 12:03 Message: Logged In: YES user_id=3066 I've clarified this paragraph in the README in revision 1.176. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 17:14 Message: Logged In: YES user_id=21627 Would the sentence be correct if the world "contains" is added between "likely" and "object"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774480&group_id=5470 From noreply@sourceforge.net Mon Jul 21 17:14:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 09:14:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-774751 ] slow socket binding & netinfo lookups Message-ID: Bugs item #774751, was opened at 2003-07-20 18:57 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: slow socket binding & netinfo lookups Initial Comment: The following code takes < 1 second to run under Python 2.1, but 20 seconds to run under Python 2.2 or 2.3 on a top- end PowerBook running OSX 10.2. It is part of the Zope startup routine. def max_server_sockets(): sl = [] while 1: try: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) s.listen(5) sl.append (s) except: break num = len(sl) for s in sl: s.close() del sl return num ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 11:14 Message: Logged In: YES user_id=44345 whoops... my apologies for not posting here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 10:50 Message: Logged In: YES user_id=31435 Attaching copious info from Skip Montanaro (skip.txt). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-21 02:05 Message: Logged In: YES user_id=29957 Is this something that should be looked at for 2.3rc2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 From noreply@sourceforge.net Mon Jul 21 17:20:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 09:20:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-554750 ] Circular reference in Index for frame Message-ID: Bugs item #554750, was opened at 2002-05-10 23:36 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554750&group_id=5470 Category: Documentation Group: Python 2.2.1 >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Noah Spurrier (noah) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Circular reference in Index for frame Initial Comment: I hope you don't mind all my anal retentive documentation bugs ;-) In the Python Library Index: http://www.python.org/dev/doc/devel/lib/genindex.html Go to 'F' and look up 'frame object'. http://www.python.org/dev/doc/devel/lib/module- signal.html#l2h-1870 It takes you to the signal documentation here: "The handler is called with two arguments: the signal number and the current stack frame (None or a frame object; see the reference manual for a description of frame objects)." Besides this circular reference, as far as I can tell the frame object and it's use in a signal handler is undocumented. Frame Objects are mentioned in the Python Reference Manual Index, but the named anchor is not correct. It does link to the correct page, but it brings you to the top of the page, whereas Frame Objects are not mentioned until much farther down the page. This is the link given in the Index: http://www.python.org/dev/doc/devel/ref/types.html#l2h- 59 The details of Frame Objects are still rather fuzzy. Yours, Noah ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-21 12:20 Message: Logged In: YES user_id=3066 1. The use of a frame object is an application issue; the documentation should tell you what it is. 2. The link was indeed wrong due to problems with our configuration of the tools we use; this has been fixed. 3. If you still think to docs on frame objects are fuzzy, please explain what didn't make sense in a new bug report. Closing this report. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-16 22:28 Message: Logged In: YES user_id=357491 The use of the frame object is up to you. Most people would use it to inspect the frame to see where they were when the signal was raised. Since the use is completely up to the user it is not specified. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=554750&group_id=5470 From noreply@sourceforge.net Mon Jul 21 17:33:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 09:33:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-774751 ] slow socket binding & netinfo lookups Message-ID: Bugs item #774751, was opened at 2003-07-20 18:57 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: slow socket binding & netinfo lookups Initial Comment: The following code takes < 1 second to run under Python 2.1, but 20 seconds to run under Python 2.2 or 2.3 on a top- end PowerBook running OSX 10.2. It is part of the Zope startup routine. def max_server_sockets(): sl = [] while 1: try: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) s.listen(5) sl.append (s) except: break num = len(sl) for s in sl: s.close() del sl return num ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 11:33 Message: Logged In: YES user_id=44345 Digging a bit deeper, it appears on Mac OS X that fake_getaddrinfo is used. That's deemed not to be thread-safe. I see three static or global variables acessed by this function: firsttime - simple guard translate - set inside the guard - readonly after that faith_prefix - same Why not push the guard and initialization code into init_socket and protect it with the getaddrinfo lock? Fake_getaddrinfo would thus be thread-safe and could be accessed without acquiring a lock. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 11:14 Message: Logged In: YES user_id=44345 whoops... my apologies for not posting here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 10:50 Message: Logged In: YES user_id=31435 Attaching copious info from Skip Montanaro (skip.txt). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-21 02:05 Message: Logged In: YES user_id=29957 Is this something that should be looked at for 2.3rc2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 From noreply@sourceforge.net Mon Jul 21 21:52:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 13:52:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-774751 ] slow socket binding & netinfo lookups Message-ID: Bugs item #774751, was opened at 2003-07-21 01:57 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) >Assigned to: Skip Montanaro (montanaro) Summary: slow socket binding & netinfo lookups Initial Comment: The following code takes < 1 second to run under Python 2.1, but 20 seconds to run under Python 2.2 or 2.3 on a top- end PowerBook running OSX 10.2. It is part of the Zope startup routine. def max_server_sockets(): sl = [] while 1: try: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) s.listen(5) sl.append (s) except: break num = len(sl) for s in sl: s.close() del sl return num ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 22:52 Message: Logged In: YES user_id=45365 I have absolutely nothing to contribute wrt. this bug. As Just is away I guess Skip is the best target for the hot patato. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 18:33 Message: Logged In: YES user_id=44345 Digging a bit deeper, it appears on Mac OS X that fake_getaddrinfo is used. That's deemed not to be thread-safe. I see three static or global variables acessed by this function: firsttime - simple guard translate - set inside the guard - readonly after that faith_prefix - same Why not push the guard and initialization code into init_socket and protect it with the getaddrinfo lock? Fake_getaddrinfo would thus be thread-safe and could be accessed without acquiring a lock. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 18:14 Message: Logged In: YES user_id=44345 whoops... my apologies for not posting here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 17:50 Message: Logged In: YES user_id=31435 Attaching copious info from Skip Montanaro (skip.txt). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-21 09:05 Message: Logged In: YES user_id=29957 Is this something that should be looked at for 2.3rc2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 From noreply@sourceforge.net Mon Jul 21 21:55:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 13:55:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-773450 ] 2.3b2 pimp.py calls non-existent routine Message-ID: Bugs item #773450, was opened at 2003-07-18 07:59 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773450&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: David Lewis (davidmlewis) Assigned to: Jack Jansen (jackjansen) Summary: 2.3b2 pimp.py calls non-existent routine Initial Comment: On line 589, there is a call to _fmtpackagename(self). No such routine is there, nor is there anything in the distribution that contains the string packagename, in any case, that looks suitable. This is in the 2.3b2 distribution. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 22:55 Message: Logged In: YES user_id=45365 Fixed on the trunk as rev. 1.27. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 16:56 Message: Logged In: YES user_id=45365 Fixed in pimp.py rev. 1.26.4.1 on the r23c1-branch. The fix will be backported to the main branch later. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773450&group_id=5470 From noreply@sourceforge.net Mon Jul 21 22:00:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 14:00:24 -0700 Subject: [Python-bugs-list] [ python-Bugs-768068 ] Explicit interp reference during build fails Message-ID: Bugs item #768068, was opened at 2003-07-08 23:44 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768068&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Skip Montanaro (montanaro) Assigned to: Jack Jansen (jackjansen) Summary: Explicit interp reference during build fails Initial Comment: I think this is MacPython-specific and not just a general Python build issue. If I explicitly reference the Python executable when building an out-of-tree extension module I get an error building the .so file because it stripped the dirname() of the python.exe file. Here's a simple example. I have a directory with a single extension module and simple setup.py. I want to build it with ~/src/python/head/dist/src/build.pg/python.exe Compilation works fine. Linkage bombs. % pwd /Users/skip/src/PyExtensions1.5/python2.2 montanaro:python2.2% ls -l total 8 -rw-r--r-- 1 skip staff 1318 Jan 21 2002 llopmodule.c -rw-rw-r-- 1 skip staff 114 Jan 21 2002 setup.py montanaro:python2.2% cat setup.py from distutils.core import setup, Extension setup(name="llop", ext_modules=[Extension("llop", ["llopmodule.c"])]) montanaro:python2.2% ~/src/python/head/dist/src/ build.pg/python.exe setup.py build running build running build_ext building 'llop' extension creating build creating build/temp.darwin-6.6-Power_Macintosh-2.3 gcc -pg -fno-strict-aliasing -Wno-long-double -no-cpp- precomp -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I/ Users/skip/src/python/head/dist/src/Include -I/Users/skip/ src/python/head/dist/src/build.pg -c llopmodule.c -o build/ temp.darwin-6.6-Power_Macintosh-2.3/llopmodule.o creating build/lib.darwin-6.6-Power_Macintosh-2.3 gcc -pg -bundle -bundle_loader python.exe build/ temp.darwin-6.6-Power_Macintosh-2.3/llopmodule.o -o build/lib.darwin-6.6-Power_Macintosh-2.3/llop.so ld: can't open: python.exe (No such file or directory, errno = 2) error: command 'gcc' failed with exit status 1 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 23:00 Message: Logged In: YES user_id=45365 This won't be fixed for 2.3, after discussion on python-dev it seems the situation is not so common, so it can wait for 2.3.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768068&group_id=5470 From noreply@sourceforge.net Mon Jul 21 22:07:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 14:07:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-766842 ] Installing documentation doesn't make it show up Message-ID: Bugs item #766842, was opened at 2003-07-06 23:42 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766842&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Installing documentation doesn't make it show up Initial Comment: If you're installing the full Python documentation through Package Manager, but you've already run the IDE previously (the common case) the new documentation doesn't show up in the Apple Help Viewer. It does show up when you remove your help preferences. Probably a bug in the registration code in PythonIDE. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 23:07 Message: Logged In: YES user_id=45365 The IDE registration code turns out to be fine, so the problem is probably that if you do AHRegisterHelpBook() for an app for which you've done so before the call is simply ignored, in stead of the app being re-examined. This makes the problem difficult to fix right now. A possible fix would be to put the "MacPython Help" and "Python Documentation" into two different apps (the former in the IDE and the latter in Python.app?), but that's too much work for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766842&group_id=5470 From noreply@sourceforge.net Mon Jul 21 22:15:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 14:15:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-765888 ] InfoPlist.strings files are UTF-16. Message-ID: Bugs item #765888, was opened at 2003-07-04 13:43 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765888&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: InfoPlist.strings files are UTF-16. Initial Comment: Comment by Edward Moy: 6) Python.framework/Versions/2.3/Resources/English.lproj/ InfoPlist.strings and Python.app/Contents/Resources/ English.lproj/InfoPlist.strings needs to be UTF-16. This needs to be fixed. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 23:15 Message: Logged In: YES user_id=45365 Fixing this would require setting the filetype to binary in the CVS repository, and I think it's unwise to do this just before 2.3 goes out, so I'm punting on it. Note that it will be difficult to fix later too, as the "-kb" flag is per- file, not per-revision, so setting the binary flag would change history. A better solution is probably to create new InfoPlist.strings files for 2.4, in a different location. Or do away with them altogether, and have them be generated (which will also solve the problem that the version numbers here have to be updated). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765888&group_id=5470 From noreply@sourceforge.net Mon Jul 21 22:25:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 14:25:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-765601 ] PackMan: per-user source install of Numeric Message-ID: Bugs item #765601, was opened at 2003-07-03 22:59 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765601&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PackMan: per-user source install of Numeric Initial Comment: Doing a current user source install from numeric causes files to be skipped. This shoulnd't give an errror message. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 23:25 Message: Logged In: YES user_id=45365 We'll "fix" this by documenting it in the description of the package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765601&group_id=5470 From noreply@sourceforge.net Mon Jul 21 22:26:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 14:26:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-764975 ] Installing 2.3b2 on to non-system disk fails Message-ID: Bugs item #764975, was opened at 2003-07-03 00:45 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764975&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Rob Managan (managan) Assigned to: Jack Jansen (jackjansen) Summary: Installing 2.3b2 on to non-system disk fails Initial Comment: When installing 2.3b2 I was allowed to choose a non-system disk. It did create an Applications folder and installed into it. Parts of the framework were installed correctly (based onmod dates) but it did not work properly. After installing on the system disk the IDE worked fine but the package manager did not except from within the IDE. I suspect double clicking on the Package Manager was trying to use an older version of python, possibly Apple's. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764975&group_id=5470 From noreply@sourceforge.net Mon Jul 21 22:38:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 14:38:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-765608 ] Binary installer says it will take 0 bytes of diskspace Message-ID: Bugs item #765608, was opened at 2003-07-03 23:18 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765608&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Binary installer says it will take 0 bytes of diskspace Initial Comment: The installer says the installation will take zero bytes of diskspace. Rumour has it this is difficult to fix, but then the readme should warn about it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765608&group_id=5470 From noreply@sourceforge.net Mon Jul 21 22:45:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 14:45:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-766210 ] Mac/OSX/Makefile assumes case-insensitive build Message-ID: Bugs item #766210, was opened at 2003-07-05 01:33 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766210&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Mac/OSX/Makefile assumes case-insensitive build Initial Comment: Mac/OSX/Makefile doesn't work on a case-sensitive filesystem, because it assumes that python.exe exists. Here's a fragment of an email conversation on the topic: ---------------- 1) In the top level Makefile, BUILDEXE is set depending on whether the filesystem is case insensitive or not. However, Mac/OSX/Makefile always assumes case-insensitivity, so there can be a conflict if python is built under Mac OS X on UFS or NFS. This is unintentional. But: I don't have a UFS file system handy right now, and visual inspection of Mac/OSX/Makefile hasn't revealed any obvious things. Could you elaborate? If all else fails send me the diff, after going through the release process. Sorry I wasn't more clear. It is the following line in Mac/ OSX/Makefile that is the problem: BUILDPYTHON=$(builddir)/python.exe This expects the top level Makefile to have added a .exe suffix, which would only happen if a case-insensitive filesystem was detected. -------------- ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 23:45 Message: Logged In: YES user_id=45365 I am at loss to why this problem still exists. On inspection it seems to be a duplicate of #677753, which was fixed 6 months ago, so the problem shouldn't have showed up in 2.3b2. I will not fix this bug for 2.3, and try to find out what is going on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766210&group_id=5470 From noreply@sourceforge.net Mon Jul 21 22:45:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 14:45:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-775309 ] button methods tkButtonDown, etc don't work Message-ID: Bugs item #775309, was opened at 2003-07-21 14:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775309&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Russell Owen (reowen) Assigned to: Nobody/Anonymous (nobody) Summary: button methods tkButtonDown, etc don't work Initial Comment: The Tkinter.Button methods tkButtonDown, etc. don't work in Python 2.2.2 or 2.3b2. Sample traceback: Traceback (most recent call last): File "/usr/local/lib/python2.2/lib-tk/Tkinter.py", line 1300, in __call__ return apply(self.func, args) File "/Users/rowen/PythonRO/RO/Wdg/ScriptWindow.py", line 90, in run exec script in globals, locals File "", line 1, in ? File "/usr/local/lib/python2.2/lib-tk/Tkinter.py", line 1831, in tkButtonDown self.tk.call('tkButtonDown', self._w) TclError: invalid command name "tkButtonDown" I'm not sure what's going on. I've not even been able to find tkButtonDown in the tcl/tk documentation, though a google search come up with some hits for Tcl/Tk 8.3 so it clearly existed or exists. Details: - This is on MacOS X 10.2.6, though I doubt it matters - Python 2.2.2 is a standard unix build with unix/X Tcl/Tk 8.4.1 (all built from source) running with Apple's X11 - MacPython 2.3b2 (via binary installer) with aqua Tcl/Tk 8.4.3 (built from source) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775309&group_id=5470 From noreply@sourceforge.net Mon Jul 21 23:04:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 15:04:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-765621 ] Packman crashes with garbage database Message-ID: Bugs item #765621, was opened at 2003-07-03 23:34 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765621&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Packman crashes with garbage database Initial Comment: Packman crashes when you feed it a random HTML document, in stead of giving a decent error message. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 00:04 Message: Logged In: YES user_id=45365 Fixed in PackageManager.py rev. 1.13. I'll be filing another bug report for plistlib later (where the real fix should be, I think). ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-07-04 01:14 Message: Logged In: YES user_id=431773 The 2.3b2-2 installer may have improved this some (I'm not sure). Most incorrect URLs I tried gave a nice explanatory error message. However, the url "http://python.org/packman" reliably gives a traceback. Here's an example: ExpatError: syntax error: line 1, column 62 File "Wapplication.py", line 45, in mainloop self.do1event(mask, wait) File "FrameWork.py", line 194, in do1event self.dispatch(event) File "FrameWork.py", line 227, in dispatch handler(event) File "FrameWork.py", line 289, in do_mouseDown handler(partcode, wid, event) File "Wapplication.py", line 203, in do_inMenuBar self.do_rawmenu(id, item, window, event) File "FrameWork.py", line 314, in do_rawmenu self.do_menu(id, item, window, event) File "FrameWork.py", line 321, in do_menu self.menubar.dispatch(id, item, window, event) File "Wapplication.py", line 445, in dispatch self.menus[id].dispatch(id, item, window, event) File "Wapplication.py", line 462, in dispatch W.CallbackCall(callback, 0, id, item, window, event) File "Wbase.py", line 684, in CallbackCall return callback() File "PackageManager.py", line 176, in domenu_openURL self.opendoc(url) File "PackageManager.py", line 150, in opendoc PackageBrowser(url) File "PackageManager.py", line 328, in __init__ messages = self.setuppimp(url) File "PackageManager.py", line 251, in setuppimp self.pimpdb.appendURL(url) File "pimp.py", line 259, in appendURL dict = plistlib.Plist.fromFile(fp) File "plistlib.py", line 211, in fromFile plist = p.parse(pathOrFile) File "plistlib.py", line 302, in parse parser.ParseFile(file) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765621&group_id=5470 From noreply@sourceforge.net Mon Jul 21 23:06:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 15:06:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-775321 ] plistlib error handling Message-ID: Bugs item #775321, was opened at 2003-07-22 00:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775321&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Just van Rossum (jvr) Summary: plistlib error handling Initial Comment: If you pass a garbage file to plistlib you can get all sorts of unexpected exceptions, for instance from the XML parser. This makes it hard to catch these errors, it would be better if plistlib caught the errors and raised a new one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775321&group_id=5470 From noreply@sourceforge.net Mon Jul 21 23:11:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 15:11:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-764615 ] PackMan reissues error messages Message-ID: Bugs item #764615, was opened at 2003-07-02 16:22 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764615&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PackMan reissues error messages Initial Comment: If PackMan gives an error or warning when installing a package it will show that warning again when installing the next package. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 00:11 Message: Logged In: YES user_id=45365 Fixed in PackageManager.py 1.14. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764615&group_id=5470 From noreply@sourceforge.net Mon Jul 21 23:12:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 15:12:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-765621 ] Packman crashes with garbage database Message-ID: Bugs item #765621, was opened at 2003-07-03 23:34 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765621&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Packman crashes with garbage database Initial Comment: Packman crashes when you feed it a random HTML document, in stead of giving a decent error message. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 00:04 Message: Logged In: YES user_id=45365 Fixed in PackageManager.py rev. 1.13. I'll be filing another bug report for plistlib later (where the real fix should be, I think). ---------------------------------------------------------------------- Comment By: Russell Owen (reowen) Date: 2003-07-04 01:14 Message: Logged In: YES user_id=431773 The 2.3b2-2 installer may have improved this some (I'm not sure). Most incorrect URLs I tried gave a nice explanatory error message. However, the url "http://python.org/packman" reliably gives a traceback. Here's an example: ExpatError: syntax error: line 1, column 62 File "Wapplication.py", line 45, in mainloop self.do1event(mask, wait) File "FrameWork.py", line 194, in do1event self.dispatch(event) File "FrameWork.py", line 227, in dispatch handler(event) File "FrameWork.py", line 289, in do_mouseDown handler(partcode, wid, event) File "Wapplication.py", line 203, in do_inMenuBar self.do_rawmenu(id, item, window, event) File "FrameWork.py", line 314, in do_rawmenu self.do_menu(id, item, window, event) File "FrameWork.py", line 321, in do_menu self.menubar.dispatch(id, item, window, event) File "Wapplication.py", line 445, in dispatch self.menus[id].dispatch(id, item, window, event) File "Wapplication.py", line 462, in dispatch W.CallbackCall(callback, 0, id, item, window, event) File "Wbase.py", line 684, in CallbackCall return callback() File "PackageManager.py", line 176, in domenu_openURL self.opendoc(url) File "PackageManager.py", line 150, in opendoc PackageBrowser(url) File "PackageManager.py", line 328, in __init__ messages = self.setuppimp(url) File "PackageManager.py", line 251, in setuppimp self.pimpdb.appendURL(url) File "pimp.py", line 259, in appendURL dict = plistlib.Plist.fromFile(fp) File "plistlib.py", line 211, in fromFile plist = p.parse(pathOrFile) File "plistlib.py", line 302, in parse parser.ParseFile(file) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765621&group_id=5470 From noreply@sourceforge.net Mon Jul 21 23:16:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 15:16:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-775328 ] Setting metaclass descriptor doesn't intercept __get__ Message-ID: Bugs item #775328, was opened at 2003-07-21 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=775328&group_id=5470 Category: Type/class unification Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Nobody/Anonymous (nobody) Summary: Setting metaclass descriptor doesn't intercept __get__ Initial Comment: When working with metaclass descriptors (that is, descriptors which live in metaclasses for the purpose of providing properties on regular classes), if you delete the descriptor from the meta-class, then re-set the descriptor to re-enable the property-like operation, subsequent accesses of the class' property do not trigger the metaclass descriptor's __get__ method. Tested on Python 2.2.3 on Win2K. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775328&group_id=5470 From noreply@sourceforge.net Mon Jul 21 23:20:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 15:20:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-775328 ] Setting metaclass descriptor doesn't intercept __get__ Message-ID: Bugs item #775328, was opened at 2003-07-21 18:16 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775328&group_id=5470 Category: Type/class unification Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Nobody/Anonymous (nobody) Summary: Setting metaclass descriptor doesn't intercept __get__ Initial Comment: When working with metaclass descriptors (that is, descriptors which live in metaclasses for the purpose of providing properties on regular classes), if you delete the descriptor from the meta-class, then re-set the descriptor to re-enable the property-like operation, subsequent accesses of the class' property do not trigger the metaclass descriptor's __get__ method. Tested on Python 2.2.3 on Win2K. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2003-07-21 18:20 Message: Logged In: YES user_id=34901 Well, Mozilla crashes every time I try to upload the file, so here's the code for the testing script... class MetaProp(object): def __init__(self, val): self.val = val def __get__(self, ob, cls=None): for k in ob.__class__.__dict__: if ob.__class__.__dict__[k] is self: delattr(ob.__class__, k) break else: raise Exception, 'not found' self.val = self.val + 1 setattr(ob, k, self.val) setattr(ob.__class__, k, self) return self.val class Meta(type): p = MetaProp(1) class C: __metaclass__ = Meta assert C.p == 2, """First increment didn't work (it does work)""" assert C.p == 3, """Second increment didn't work (it doesn't)""" assert C.p == 4, """Third increment didn't work (never get this far)""" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775328&group_id=5470 From noreply@sourceforge.net Mon Jul 21 23:43:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 15:43:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-775061 ] 2 problems with IDLE Message-ID: Bugs item #775061, was opened at 2003-07-21 17:08 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775061&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Kurt B. Kaiser (kbk) Summary: 2 problems with IDLE Initial Comment: Lib/idlelib/idle.py should use #!/usr/bin/env python not /usr/bin/python so the user can modify their path to execute the correct version of python. In Lib/idlelib/rpc.py around line 623, svr.register (svr is an RPCServer instance) is called, but there is no register method AFAICT. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 00:43 Message: Logged In: YES user_id=21627 I fail to see the first problem. Shouldn't distutils replace the path in #! with sys.exec_prefix? /usr/bin/env should *not* be used, as this might be a different python than the one IDLE was installed for. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775061&group_id=5470 From noreply@sourceforge.net Mon Jul 21 23:51:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 15:51:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-775340 ] OSX 'freeze' bug Message-ID: Bugs item #775340, was opened at 2003-07-21 22: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=775340&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: justin (justinlk) Assigned to: Nobody/Anonymous (nobody) Summary: OSX 'freeze' bug Initial Comment: When trying to 'make' a frozen script on OSX framework install, it looks for and fails to find config.o (It says: config.o frozen.o M_BaseHTTPServer.o [...] /Library/ Frameworks/Python.framework/Versions/2.3/lib/ python2.3/config/libpython.a -o Study make: config.o: Command not found make: *** [Study] Error 127) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775340&group_id=5470 From noreply@sourceforge.net Tue Jul 22 00:54:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 16:54:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-775353 ] IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work Message-ID: Bugs item #775353, was opened at 2003-07-21 16: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=775353&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Shomphe (mshomphe) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work Initial Comment: Info: -Python Version: Python 2.3c1 (#44, Jul 18 2003, 14:32: 36) [MSC v.1200 32 bit (Intel)] on win32 -IDLE Version:IDLE 1.0rc1 -OS: Windows 2000 SP4 -Source: Installed from Installer on website (http://www. python.org/ftp/python/2.3/Python-2.3c1.exe) Behavior: In the "File" dropdown menu in IDLE, the listed keybind for "Save As" is Ctrl+Shift+S. This does not work. When you hit Ctrl+Shift+S, nothing happens. Additionally, the keybind for "Save Copy As...", Alt+Shift+S, does not work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775353&group_id=5470 From noreply@sourceforge.net Tue Jul 22 01:32:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 17:32:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-775353 ] IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work Message-ID: Bugs item #775353, was opened at 2003-07-21 16:54 Message generated for change (Comment added) made by mshomphe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775353&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Shomphe (mshomphe) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work Initial Comment: Info: -Python Version: Python 2.3c1 (#44, Jul 18 2003, 14:32: 36) [MSC v.1200 32 bit (Intel)] on win32 -IDLE Version:IDLE 1.0rc1 -OS: Windows 2000 SP4 -Source: Installed from Installer on website (http://www. python.org/ftp/python/2.3/Python-2.3c1.exe) Behavior: In the "File" dropdown menu in IDLE, the listed keybind for "Save As" is Ctrl+Shift+S. This does not work. When you hit Ctrl+Shift+S, nothing happens. Additionally, the keybind for "Save Copy As...", Alt+Shift+S, does not work. ---------------------------------------------------------------------- >Comment By: Matthew Shomphe (mshomphe) Date: 2003-07-21 17:32 Message: Logged In: YES user_id=716326 Checking through the code, it seems that the problem is in the file "configHandler.py". The bindings are assigned with _lowercase_ letters: '<>': [''], '<>': [''], So the keybindings will work when CAPSLOCK is active. Otherwise, it won't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775353&group_id=5470 From noreply@sourceforge.net Tue Jul 22 03:19:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 19:19:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-775061 ] 2 problems with IDLE Message-ID: Bugs item #775061, was opened at 2003-07-21 11:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775061&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Kurt B. Kaiser (kbk) Summary: 2 problems with IDLE Initial Comment: Lib/idlelib/idle.py should use #!/usr/bin/env python not /usr/bin/python so the user can modify their path to execute the correct version of python. In Lib/idlelib/rpc.py around line 623, svr.register (svr is an RPCServer instance) is called, but there is no register method AFAICT. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-21 22:19 Message: Logged In: YES user_id=33168 Hmmm, I do remember something about distutils rewriting the line, but I'm not sure. My problem was that I was running an uninstalled version in the CVS tree: ./Lib/idlelib/idle Perhaps this isn't a bug. RPCServer still appears to be a problem either way. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-21 18:43 Message: Logged In: YES user_id=21627 I fail to see the first problem. Shouldn't distutils replace the path in #! with sys.exec_prefix? /usr/bin/env should *not* be used, as this might be a different python than the one IDLE was installed for. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775061&group_id=5470 From noreply@sourceforge.net Tue Jul 22 03:29:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 19:29:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-775414 ] bsddb3 hash craps out with threads Message-ID: Bugs item #775414, was opened at 2003-07-21 22:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=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: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775414&group_id=5470 From noreply@sourceforge.net Tue Jul 22 03:42:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 19:42:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-774751 ] slow socket binding & netinfo lookups Message-ID: Bugs item #774751, was opened at 2003-07-20 18:57 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Skip Montanaro (montanaro) Summary: slow socket binding & netinfo lookups Initial Comment: The following code takes < 1 second to run under Python 2.1, but 20 seconds to run under Python 2.2 or 2.3 on a top- end PowerBook running OSX 10.2. It is part of the Zope startup routine. def max_server_sockets(): sl = [] while 1: try: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) s.listen(5) sl.append (s) except: break num = len(sl) for s in sl: s.close() del sl return num ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 21:42 Message: Logged In: YES user_id=44345 I think we've concluded that it's okay to ship 2.3 with this problem unresolved, however I'm completely befuddled at the moment. I wrote this simple program: #include #include #include #include #include int main(int argc, char **argv) { int i; struct addrinfo hints, *res; int error; struct timeval t, u; hints.ai_family = AF_INET; hints.ai_socktype = SOCK_DGRAM; /*dummy*/ hints.ai_flags = AI_PASSIVE; printf("start\n"); for (i=0; i<100; i++) { gettimeofday(&t, NULL); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, NULL); fprintf(stderr, "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); freeaddrinfo(res); } printf("finish\n"); } When run on my Mac, it takes between 2 and 7 microseconds per getaddrinfo call. The exact same instrumented call inside socketmodule.c:setipaddr at line 700 takes about 150 *milli*seconds per call. I tried eliminating the Py_{BEGIN,END}_ALLOW_THREADS calls as well as the ACQUIRE and RELEASE of the getaddrinfo lock. That had no effect on the call. I also tweaked the compile like to run just the C preprocessor (gcc -E instead of gcc -g) and checked the output: ... hints.ai_family = af; hints.ai_socktype = 2; hints.ai_flags = 0x00000001; { PyThreadState *_save; _save = PyEval_SaveThread(); PyThread_acquire_lock(netdb_lock, 1); gettimeofday(&t, 0); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, 0); fprintf((&__sF[2]), "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); PyEval_RestoreThread(_save); } ... otool -L run against both the test program and _socket.so indicate that both refer to just one shared library (/usr/lib/libSystem.B.dylib), so both should be calling the same routine. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 15:52 Message: Logged In: YES user_id=45365 I have absolutely nothing to contribute wrt. this bug. As Just is away I guess Skip is the best target for the hot patato. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 11:33 Message: Logged In: YES user_id=44345 Digging a bit deeper, it appears on Mac OS X that fake_getaddrinfo is used. That's deemed not to be thread-safe. I see three static or global variables acessed by this function: firsttime - simple guard translate - set inside the guard - readonly after that faith_prefix - same Why not push the guard and initialization code into init_socket and protect it with the getaddrinfo lock? Fake_getaddrinfo would thus be thread-safe and could be accessed without acquiring a lock. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 11:14 Message: Logged In: YES user_id=44345 whoops... my apologies for not posting here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 10:50 Message: Logged In: YES user_id=31435 Attaching copious info from Skip Montanaro (skip.txt). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-21 02:05 Message: Logged In: YES user_id=29957 Is this something that should be looked at for 2.3rc2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 From noreply@sourceforge.net Tue Jul 22 03:48:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 19:48:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-774751 ] slow socket binding & netinfo lookups Message-ID: Bugs item #774751, was opened at 2003-07-20 18:57 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Skip Montanaro (montanaro) Summary: slow socket binding & netinfo lookups Initial Comment: The following code takes < 1 second to run under Python 2.1, but 20 seconds to run under Python 2.2 or 2.3 on a top- end PowerBook running OSX 10.2. It is part of the Zope startup routine. def max_server_sockets(): sl = [] while 1: try: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) s.listen(5) sl.append (s) except: break num = len(sl) for s in sl: s.close() del sl return num ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 21:48 Message: Logged In: YES user_id=44345 Another little observation. I ran the getaddr program (with the loop cranked up to 10 million iterations) while the top command was running. The lookupd process didn't show on the radar at all. While running the Python script however, lookupd consumed about 50% of the cpu. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 21:42 Message: Logged In: YES user_id=44345 I think we've concluded that it's okay to ship 2.3 with this problem unresolved, however I'm completely befuddled at the moment. I wrote this simple program: #include #include #include #include #include int main(int argc, char **argv) { int i; struct addrinfo hints, *res; int error; struct timeval t, u; hints.ai_family = AF_INET; hints.ai_socktype = SOCK_DGRAM; /*dummy*/ hints.ai_flags = AI_PASSIVE; printf("start\n"); for (i=0; i<100; i++) { gettimeofday(&t, NULL); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, NULL); fprintf(stderr, "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); freeaddrinfo(res); } printf("finish\n"); } When run on my Mac, it takes between 2 and 7 microseconds per getaddrinfo call. The exact same instrumented call inside socketmodule.c:setipaddr at line 700 takes about 150 *milli*seconds per call. I tried eliminating the Py_{BEGIN,END}_ALLOW_THREADS calls as well as the ACQUIRE and RELEASE of the getaddrinfo lock. That had no effect on the call. I also tweaked the compile like to run just the C preprocessor (gcc -E instead of gcc -g) and checked the output: ... hints.ai_family = af; hints.ai_socktype = 2; hints.ai_flags = 0x00000001; { PyThreadState *_save; _save = PyEval_SaveThread(); PyThread_acquire_lock(netdb_lock, 1); gettimeofday(&t, 0); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, 0); fprintf((&__sF[2]), "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); PyEval_RestoreThread(_save); } ... otool -L run against both the test program and _socket.so indicate that both refer to just one shared library (/usr/lib/libSystem.B.dylib), so both should be calling the same routine. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 15:52 Message: Logged In: YES user_id=45365 I have absolutely nothing to contribute wrt. this bug. As Just is away I guess Skip is the best target for the hot patato. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 11:33 Message: Logged In: YES user_id=44345 Digging a bit deeper, it appears on Mac OS X that fake_getaddrinfo is used. That's deemed not to be thread-safe. I see three static or global variables acessed by this function: firsttime - simple guard translate - set inside the guard - readonly after that faith_prefix - same Why not push the guard and initialization code into init_socket and protect it with the getaddrinfo lock? Fake_getaddrinfo would thus be thread-safe and could be accessed without acquiring a lock. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 11:14 Message: Logged In: YES user_id=44345 whoops... my apologies for not posting here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 10:50 Message: Logged In: YES user_id=31435 Attaching copious info from Skip Montanaro (skip.txt). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-21 02:05 Message: Logged In: YES user_id=29957 Is this something that should be looked at for 2.3rc2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 From noreply@sourceforge.net Tue Jul 22 04:09:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 20:09:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 12:35 Message generated for change (Comment added) made by theaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2003-07-22 03:09 Message: Logged In: YES user_id=827666 Hello. I just downloaded 2.3c1. I failed test_time as well. I was going to submit a new bug, but then I saw this thread. I hope this is the right place. test_time test test_time failed -- Traceback (most recent call last): File "/home/tim/Download/Python-2.3c1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/tim/Download/Python-2.3c1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST 227 tests OK. 1 test failed: test_time 27 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_email_codecs test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on linux2. make: *** [test] Error 1 For what it's worth, time seems to work... $ ./python -c 'import time; print time.tzname' ('EST', 'EDT') $ cat /proc/version Linux version 2.4.20 (root@mrbun) (gcc version 2.95.3 20010315 (release)) #11 Sat Nov 30 05:52:58 EST 2002 Tim ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-13 02:28 Message: Logged In: YES user_id=357491 I uploaded a new version of the patch. Give it a try and see what happens if you could. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-10 17:11 Message: Logged In: YES user_id=357491 Barry says you need to do the following to truly test the patch: - check out the head - make distclean - apply the patch - autoreconf - ./configure --with-pydebug - make test Apparently autoreconf regenerates something for autoconf and that has to be done. Learn something new everyday. Can you give that a shot, Torsten? If that still fails it is going to take some work to figure this one out. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-10 07:58 Message: Logged In: YES user_id=269193 no, sorry, no success! * re-compiled python, as expected the test failed again. * patch -p0 <../tzset4.diff * made a "make distclean" * ./configure again, looked nice, no chached stuff. * make * make test >>> failed again !!! anything i could check to help? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-10 04:37 Message: Logged In: YES user_id=80475 Tonight, test_time also failed for me and then worked on the next pass. Am using WinME and Py2.3b2+. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-09 18:30 Message: Logged In: YES user_id=269193 sorry, problem! hard drive scambled. i have to re-install python anyway. i will see if the test fails again, and then i try to apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 17:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 05:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 02:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 17:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 15:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Tue Jul 22 07:48:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 21 Jul 2003 23:48:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-763708 ] Failures in test_macostools Message-ID: Bugs item #763708, was opened at 2003-06-30 23:54 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-21 23:48 Message: Logged In: YES user_id=357491 Tested and still fails with a CVS update on 2003-07-21. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-19 17:30 Message: Logged In: YES user_id=45365 This seems to be fixed in 2.3c1. Could you please test? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 11:03 Message: Logged In: YES user_id=357491 OK, so the problem seems to be coming from Mac/Modules/file/ _Filemodule.c and the File_FSGetResourceForkName function (printing the result just prints "ERROR"). The online docs for FSGetResourceForkName (which is pretty much all that is called in that function) can be found at http://developer.apple.com/ documentation/Carbon/Reference/File_Manager/file_manager/ function_group_20.html#//apple_ref/c/func/ FSGetResourceForkName . Now it looks like the error is an OS X error and has nothing to do with Python. The error (-1402) means that the fork name is syntactically invalid. I don't see how this can mean anything, though, since FSGetResourceForkName's only argument is a pointer to store the result of the call into. The only thing I can think of that might be causing this error from Python's side is that a resource fork does not exist when the call is made. But this is just a guess so I could be wrong. Jack, I am going to be gone from July 13 until July 21, so if you need any debugging info from me before 2.3 final goes out I am afraid it will have to happen soon. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:42 Message: Logged In: YES user_id=357491 OK, Jack, here is your info: - 10.2.6 - Python 2.3b2+ straight from CVS (only way to code =) - HFS+ I believe (Finder says my HD is Mac OS Extended) Ran the test from my CVS tree with my installed version of Python 2.3b2+ (I can't do anything the standard way). I just ran it with the installed copy from the installed test directory and got the errors. I also just ran it with the compiled copy but not installed Python executable in my CVS tree and once again got the error. I noticed this came up, for me at least, when I was checking a patch for posixpath.py (which was applied to CVS). I checked the code, though, and didn't find a problem where anything changed to posixpath.py would affect it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 04:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply@sourceforge.net Tue Jul 22 09:50:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 01:50:39 -0700 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 richiehindle 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: Nobody/Anonymous (nobody) 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: 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@sourceforge.net Tue Jul 22 10:14:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 02:14:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-775535 ] Tooltip-window doesn't vanish if... Message-ID: Bugs item #775535, was opened at 2003-07-22 11:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775535&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Lingl (glingl) Assigned to: Nobody/Anonymous (nobody) Summary: Tooltip-window doesn't vanish if... Initial Comment: When entering in the shell window of IDLE: >>> len( a tooltip-window appears with content len(object) -> integer Now, when deleting these four characters (or at least the opening parentheses) the tooltip-window remains open. I can enter other expressions, writing even behind this tooltip-window and it vanishes only - when clicking the shell-window with the mouse - when minimizing and remaximizing the shell-window - wehn using another function call and typing a new opening parentheses. It should vanish immediately, when the opening parentheses is deleted. Regards, Gregor ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775535&group_id=5470 From noreply@sourceforge.net Tue Jul 22 10:31:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 02:31:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-775541 ] idle.py doesn't accept ( in some cases Message-ID: Bugs item #775541, was opened at 2003-07-22 11:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775541&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Gregor Lingl (glingl) Assigned to: Nobody/Anonymous (nobody) Summary: idle.py doesn't accept ( in some cases Initial Comment: I start IDLE in one-process-mode, in order to be able to use turtle.py in interactive mode. i:\python23\python.exe idle.py -n I enter in the shell-window: Python 2.3c1 (#44, Jul 18 2003, 14:32:36) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0rc1 ==== No Subprocess ==== >>> from turtle import * >>> Exception in Tkinter callback Traceback (most recent call last): File "I:\Python23\lib\lib-tk\Tkinter.py", line 1345, in __call__ return self.func(*args) File "i:\python23\lib\idlelib\CallTips.py", line 47, in paren_open_event arg_text = self.fetch_tip(name) File "i:\python23\lib\idlelib\CallTips.py", line 106, in fetch_tip return get_arg_text(entity) File "i:\python23\lib\idlelib\CallTips.py", line 165, in get_arg_text doc = getattr(ob, "__doc__", "").lstrip() AttributeError: 'NoneType' object has no attribute 'lstrip' forward( Just after typing the opening parentheses after the function name forward the shown error-message appears, and the just typed in forward( is appended to it. When I continue e.g. with 50), the turtle does, what I want. The same with all following function-calls. Maybe the reason for this bug lies (in some way) in turtle.py. Nevertheless, IMHO IDLE SHOULD accept modules like turtle.py withoult breaking (I can't understand how getattr with 3. arg "" can return NoneType at all. Or is this a bug in getattr?) Interestingly IDLE started ordinarily in multiprocess mode doesn't show this behaviour. >>> from turtle import * >>> forward(50 Alas! It's not recommended to complete this, as then IDLE would hang from other reasons ... Regards, Gregor ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775541&group_id=5470 From noreply@sourceforge.net Tue Jul 22 10:34:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 02:34:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-775544 ] Tk.quit leads to crash in python.exe Message-ID: Bugs item #775544, was opened at 2003-07-22 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=775544&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Dennis Benzinger (dcbbcd) Assigned to: Nobody/Anonymous (nobody) Summary: Tk.quit leads to crash in python.exe Initial Comment: The following program reliably crashes python.exe (2.3 RC1) on Win XP - SP1: import Tkinter tk = Tkinter.Tk() quit_btn = Tkinter.Button(tk, text='quit', #command=tk.quit) # This crashes command=tk.destroy) # This works quit_btn.pack() Tkinter.mainloop() The error message is something like (bad english translation): The instruction in "0x77f4b2ab" points to "0x00000028". The memory can't be read. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775544&group_id=5470 From noreply@sourceforge.net Tue Jul 22 14:44:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 06:44:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-775328 ] Setting metaclass descriptor doesn't intercept __get__ Message-ID: Bugs item #775328, was opened at 2003-07-21 23:16 Message generated for change (Settings changed) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775328&group_id=5470 Category: Type/class unification Group: Python 2.2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) >Assigned to: Michael Hudson (mwh) Summary: Setting metaclass descriptor doesn't intercept __get__ Initial Comment: When working with metaclass descriptors (that is, descriptors which live in metaclasses for the purpose of providing properties on regular classes), if you delete the descriptor from the meta-class, then re-set the descriptor to re-enable the property-like operation, subsequent accesses of the class' property do not trigger the metaclass descriptor's __get__ method. Tested on Python 2.2.3 on Win2K. ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-07-22 14:43 Message: Logged In: YES user_id=6656 Mike, MetaProp is a non-data descriptor, and so overriden by the contents of __dict__! Adding a dummy __set__ to MetaProp makes the asserts pass. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2003-07-21 23:20 Message: Logged In: YES user_id=34901 Well, Mozilla crashes every time I try to upload the file, so here's the code for the testing script... class MetaProp(object): def __init__(self, val): self.val = val def __get__(self, ob, cls=None): for k in ob.__class__.__dict__: if ob.__class__.__dict__[k] is self: delattr(ob.__class__, k) break else: raise Exception, 'not found' self.val = self.val + 1 setattr(ob, k, self.val) setattr(ob.__class__, k, self) return self.val class Meta(type): p = MetaProp(1) class C: __metaclass__ = Meta assert C.p == 2, """First increment didn't work (it does work)""" assert C.p == 3, """Second increment didn't work (it doesn't)""" assert C.p == 4, """Third increment didn't work (never get this far)""" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775328&group_id=5470 From noreply@sourceforge.net Tue Jul 22 14:46:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 06:46:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-765601 ] PackMan: per-user source install of Numeric Message-ID: Bugs item #765601, was opened at 2003-07-03 22:59 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765601&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PackMan: per-user source install of Numeric Initial Comment: Doing a current user source install from numeric causes files to be skipped. This shoulnd't give an errror message. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 23:25 Message: Logged In: YES user_id=45365 We'll "fix" this by documenting it in the description of the package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765601&group_id=5470 From noreply@sourceforge.net Tue Jul 22 15:09:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 07:09:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-774751 ] slow socket binding & netinfo lookups Message-ID: Bugs item #774751, was opened at 2003-07-20 18:57 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Pending >Resolution: Postponed Priority: 5 Submitted By: Stuart Bishop (zenzen) >Assigned to: Just van Rossum (jvr) Summary: slow socket binding & netinfo lookups Initial Comment: The following code takes < 1 second to run under Python 2.1, but 20 seconds to run under Python 2.2 or 2.3 on a top- end PowerBook running OSX 10.2. It is part of the Zope startup routine. def max_server_sockets(): sl = [] while 1: try: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) s.listen(5) sl.append (s) except: break num = len(sl) for s in sl: s.close() del sl return num ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-22 09:08 Message: Logged In: YES user_id=44345 Putting this on the back burner for now and assigning to Just as a present for when he returns ;-). I haven't been able to resolve the problem and Apple tells me that getaddrinfo was completely rewritten for 10.3 (Panther). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 21:48 Message: Logged In: YES user_id=44345 Another little observation. I ran the getaddr program (with the loop cranked up to 10 million iterations) while the top command was running. The lookupd process didn't show on the radar at all. While running the Python script however, lookupd consumed about 50% of the cpu. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 21:42 Message: Logged In: YES user_id=44345 I think we've concluded that it's okay to ship 2.3 with this problem unresolved, however I'm completely befuddled at the moment. I wrote this simple program: #include #include #include #include #include int main(int argc, char **argv) { int i; struct addrinfo hints, *res; int error; struct timeval t, u; hints.ai_family = AF_INET; hints.ai_socktype = SOCK_DGRAM; /*dummy*/ hints.ai_flags = AI_PASSIVE; printf("start\n"); for (i=0; i<100; i++) { gettimeofday(&t, NULL); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, NULL); fprintf(stderr, "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); freeaddrinfo(res); } printf("finish\n"); } When run on my Mac, it takes between 2 and 7 microseconds per getaddrinfo call. The exact same instrumented call inside socketmodule.c:setipaddr at line 700 takes about 150 *milli*seconds per call. I tried eliminating the Py_{BEGIN,END}_ALLOW_THREADS calls as well as the ACQUIRE and RELEASE of the getaddrinfo lock. That had no effect on the call. I also tweaked the compile like to run just the C preprocessor (gcc -E instead of gcc -g) and checked the output: ... hints.ai_family = af; hints.ai_socktype = 2; hints.ai_flags = 0x00000001; { PyThreadState *_save; _save = PyEval_SaveThread(); PyThread_acquire_lock(netdb_lock, 1); gettimeofday(&t, 0); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, 0); fprintf((&__sF[2]), "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); PyEval_RestoreThread(_save); } ... otool -L run against both the test program and _socket.so indicate that both refer to just one shared library (/usr/lib/libSystem.B.dylib), so both should be calling the same routine. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 15:52 Message: Logged In: YES user_id=45365 I have absolutely nothing to contribute wrt. this bug. As Just is away I guess Skip is the best target for the hot patato. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 11:33 Message: Logged In: YES user_id=44345 Digging a bit deeper, it appears on Mac OS X that fake_getaddrinfo is used. That's deemed not to be thread-safe. I see three static or global variables acessed by this function: firsttime - simple guard translate - set inside the guard - readonly after that faith_prefix - same Why not push the guard and initialization code into init_socket and protect it with the getaddrinfo lock? Fake_getaddrinfo would thus be thread-safe and could be accessed without acquiring a lock. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 11:14 Message: Logged In: YES user_id=44345 whoops... my apologies for not posting here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 10:50 Message: Logged In: YES user_id=31435 Attaching copious info from Skip Montanaro (skip.txt). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-21 02:05 Message: Logged In: YES user_id=29957 Is this something that should be looked at for 2.3rc2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 From noreply@sourceforge.net Tue Jul 22 15:27:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 07:27:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-774751 ] slow socket binding & netinfo lookups Message-ID: Bugs item #774751, was opened at 2003-07-20 19:57 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Open Resolution: Postponed Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Just van Rossum (jvr) Summary: slow socket binding & netinfo lookups Initial Comment: The following code takes < 1 second to run under Python 2.1, but 20 seconds to run under Python 2.2 or 2.3 on a top- end PowerBook running OSX 10.2. It is part of the Zope startup routine. def max_server_sockets(): sl = [] while 1: try: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) s.listen(5) sl.append (s) except: break num = len(sl) for s in sl: s.close() del sl return num ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 10:27 Message: Logged In: YES user_id=12800 Apple also said getaddrinfo has been "thread safe for a while", right? It sounds to me like our approach should be to write the code as if it were and as if it were fast, and assume Apple has/will get their act together on this. Agreed that we should do nothing here for Python 2.3. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-22 10:08 Message: Logged In: YES user_id=44345 Putting this on the back burner for now and assigning to Just as a present for when he returns ;-). I haven't been able to resolve the problem and Apple tells me that getaddrinfo was completely rewritten for 10.3 (Panther). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 22:48 Message: Logged In: YES user_id=44345 Another little observation. I ran the getaddr program (with the loop cranked up to 10 million iterations) while the top command was running. The lookupd process didn't show on the radar at all. While running the Python script however, lookupd consumed about 50% of the cpu. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 22:42 Message: Logged In: YES user_id=44345 I think we've concluded that it's okay to ship 2.3 with this problem unresolved, however I'm completely befuddled at the moment. I wrote this simple program: #include #include #include #include #include int main(int argc, char **argv) { int i; struct addrinfo hints, *res; int error; struct timeval t, u; hints.ai_family = AF_INET; hints.ai_socktype = SOCK_DGRAM; /*dummy*/ hints.ai_flags = AI_PASSIVE; printf("start\n"); for (i=0; i<100; i++) { gettimeofday(&t, NULL); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, NULL); fprintf(stderr, "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); freeaddrinfo(res); } printf("finish\n"); } When run on my Mac, it takes between 2 and 7 microseconds per getaddrinfo call. The exact same instrumented call inside socketmodule.c:setipaddr at line 700 takes about 150 *milli*seconds per call. I tried eliminating the Py_{BEGIN,END}_ALLOW_THREADS calls as well as the ACQUIRE and RELEASE of the getaddrinfo lock. That had no effect on the call. I also tweaked the compile like to run just the C preprocessor (gcc -E instead of gcc -g) and checked the output: ... hints.ai_family = af; hints.ai_socktype = 2; hints.ai_flags = 0x00000001; { PyThreadState *_save; _save = PyEval_SaveThread(); PyThread_acquire_lock(netdb_lock, 1); gettimeofday(&t, 0); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, 0); fprintf((&__sF[2]), "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); PyEval_RestoreThread(_save); } ... otool -L run against both the test program and _socket.so indicate that both refer to just one shared library (/usr/lib/libSystem.B.dylib), so both should be calling the same routine. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 16:52 Message: Logged In: YES user_id=45365 I have absolutely nothing to contribute wrt. this bug. As Just is away I guess Skip is the best target for the hot patato. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 12:33 Message: Logged In: YES user_id=44345 Digging a bit deeper, it appears on Mac OS X that fake_getaddrinfo is used. That's deemed not to be thread-safe. I see three static or global variables acessed by this function: firsttime - simple guard translate - set inside the guard - readonly after that faith_prefix - same Why not push the guard and initialization code into init_socket and protect it with the getaddrinfo lock? Fake_getaddrinfo would thus be thread-safe and could be accessed without acquiring a lock. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 12:14 Message: Logged In: YES user_id=44345 whoops... my apologies for not posting here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 11:50 Message: Logged In: YES user_id=31435 Attaching copious info from Skip Montanaro (skip.txt). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-21 03:05 Message: Logged In: YES user_id=29957 Is this something that should be looked at for 2.3rc2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 From noreply@sourceforge.net Tue Jul 22 15:32:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 07:32:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-765608 ] Binary installer says it will take 0 bytes of diskspace Message-ID: Bugs item #765608, was opened at 2003-07-03 23:18 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765608&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Binary installer says it will take 0 bytes of diskspace Initial Comment: The installer says the installation will take zero bytes of diskspace. Rumour has it this is difficult to fix, but then the readme should warn about it. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 16:32 Message: Logged In: YES user_id=45365 Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765608&group_id=5470 From noreply@sourceforge.net Tue Jul 22 15:35:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 07:35:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-775328 ] Setting metaclass descriptor doesn't intercept __get__ Message-ID: Bugs item #775328, was opened at 2003-07-21 18:16 Message generated for change (Comment added) made by mcfletch You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775328&group_id=5470 Category: Type/class unification Group: Python 2.2.3 Status: Closed Resolution: Invalid Priority: 5 Submitted By: Mike C. Fletcher (mcfletch) Assigned to: Michael Hudson (mwh) Summary: Setting metaclass descriptor doesn't intercept __get__ Initial Comment: When working with metaclass descriptors (that is, descriptors which live in metaclasses for the purpose of providing properties on regular classes), if you delete the descriptor from the meta-class, then re-set the descriptor to re-enable the property-like operation, subsequent accesses of the class' property do not trigger the metaclass descriptor's __get__ method. Tested on Python 2.2.3 on Win2K. ---------------------------------------------------------------------- >Comment By: Mike C. Fletcher (mcfletch) Date: 2003-07-22 10:35 Message: Logged In: YES user_id=34901 duh! sorry about that. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-22 09:43 Message: Logged In: YES user_id=6656 Mike, MetaProp is a non-data descriptor, and so overriden by the contents of __dict__! Adding a dummy __set__ to MetaProp makes the asserts pass. ---------------------------------------------------------------------- Comment By: Mike C. Fletcher (mcfletch) Date: 2003-07-21 18:20 Message: Logged In: YES user_id=34901 Well, Mozilla crashes every time I try to upload the file, so here's the code for the testing script... class MetaProp(object): def __init__(self, val): self.val = val def __get__(self, ob, cls=None): for k in ob.__class__.__dict__: if ob.__class__.__dict__[k] is self: delattr(ob.__class__, k) break else: raise Exception, 'not found' self.val = self.val + 1 setattr(ob, k, self.val) setattr(ob.__class__, k, self) return self.val class Meta(type): p = MetaProp(1) class C: __metaclass__ = Meta assert C.p == 2, """First increment didn't work (it does work)""" assert C.p == 3, """Second increment didn't work (it doesn't)""" assert C.p == 4, """Third increment didn't work (never get this far)""" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775328&group_id=5470 From noreply@sourceforge.net Tue Jul 22 16:22:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 08:22:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-763708 ] Failures in test_macostools Message-ID: Bugs item #763708, was opened at 2003-07-01 08:54 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 17:22 Message: Logged In: YES user_id=45365 Brett, please try the following: >>> import Carbon.File >>> Carbon.File.FSGetResourceForkName() u'RESOURCE_FORK' >>> You mention it prints ERROR for you, I'd like to see exactly what it prints (u"ERROR"? "ERROR"? ERROR?). And a bit more information I need to try and duplicate the problem: 1. Are you using a framework build or a straight build? 2. Is your /Users/drifty directory in yoor root partition? 3. Could you check that there are no test_support.TESTFN or test_support.TESTFN + '2' turds on your system? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 08:48 Message: Logged In: YES user_id=357491 Tested and still fails with a CVS update on 2003-07-21. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-20 02:30 Message: Logged In: YES user_id=45365 This seems to be fixed in 2.3c1. Could you please test? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 20:03 Message: Logged In: YES user_id=357491 OK, so the problem seems to be coming from Mac/Modules/file/ _Filemodule.c and the File_FSGetResourceForkName function (printing the result just prints "ERROR"). The online docs for FSGetResourceForkName (which is pretty much all that is called in that function) can be found at http://developer.apple.com/ documentation/Carbon/Reference/File_Manager/file_manager/ function_group_20.html#//apple_ref/c/func/ FSGetResourceForkName . Now it looks like the error is an OS X error and has nothing to do with Python. The error (-1402) means that the fork name is syntactically invalid. I don't see how this can mean anything, though, since FSGetResourceForkName's only argument is a pointer to store the result of the call into. The only thing I can think of that might be causing this error from Python's side is that a resource fork does not exist when the call is made. But this is just a guess so I could be wrong. Jack, I am going to be gone from July 13 until July 21, so if you need any debugging info from me before 2.3 final goes out I am afraid it will have to happen soon. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 22:42 Message: Logged In: YES user_id=357491 OK, Jack, here is your info: - 10.2.6 - Python 2.3b2+ straight from CVS (only way to code =) - HFS+ I believe (Finder says my HD is Mac OS Extended) Ran the test from my CVS tree with my installed version of Python 2.3b2+ (I can't do anything the standard way). I just ran it with the installed copy from the installed test directory and got the errors. I also just ran it with the compiled copy but not installed Python executable in my CVS tree and once again got the error. I noticed this came up, for me at least, when I was checking a patch for posixpath.py (which was applied to CVS). I checked the code, though, and didn't find a problem where anything changed to posixpath.py would affect it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 13:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply@sourceforge.net Tue Jul 22 19:10:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 11:10:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-669036 ] zipimport doesn't support prepended junk Message-ID: Bugs item #669036, was opened at 2003-01-16 14:15 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669036&group_id=5470 Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 6 Submitted By: Just van Rossum (jvr) Assigned to: Just van Rossum (jvr) Summary: zipimport doesn't support prepended junk Initial Comment: Zip archives may be appended to/prepended by arbitrary data, but this is not supported by zipimport. zipfile.py does support this. Unfortunately there's a fair amount of offset juggling going on, so a fix is not completely straightforward. This should be fixed before 2.3a2. zipimport *also* doesn't support Zip archives that have a comment attached at the end of the file, but this is less important IMO. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2003-07-22 20:10 Message: Logged In: YES user_id=11105 See sf #775637. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=669036&group_id=5470 From noreply@sourceforge.net Tue Jul 22 19:12:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 11:12:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-775353 ] IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work Message-ID: Bugs item #775353, was opened at 2003-07-21 18:54 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775353&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthew Shomphe (mshomphe) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work Initial Comment: Info: -Python Version: Python 2.3c1 (#44, Jul 18 2003, 14:32: 36) [MSC v.1200 32 bit (Intel)] on win32 -IDLE Version:IDLE 1.0rc1 -OS: Windows 2000 SP4 -Source: Installed from Installer on website (http://www. python.org/ftp/python/2.3/Python-2.3c1.exe) Behavior: In the "File" dropdown menu in IDLE, the listed keybind for "Save As" is Ctrl+Shift+S. This does not work. When you hit Ctrl+Shift+S, nothing happens. Additionally, the keybind for "Save Copy As...", Alt+Shift+S, does not work. ---------------------------------------------------------------------- Comment By: Matthew Shomphe (mshomphe) Date: 2003-07-21 19:32 Message: Logged In: YES user_id=716326 Checking through the code, it seems that the problem is in the file "configHandler.py". The bindings are assigned with _lowercase_ letters: '<>': [''], '<>': [''], So the keybindings will work when CAPSLOCK is active. Otherwise, it won't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775353&group_id=5470 From noreply@sourceforge.net Tue Jul 22 19:42:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 11:42:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-763708 ] Failures in test_macostools Message-ID: Bugs item #763708, was opened at 2003-06-30 23:54 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: Fixed Priority: 5 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-22 11:42 Message: Logged In: YES user_id=357491 The Carbon.File.FSGetResourceForkName() returns u'\U00520045\U0053004f\U00550052\U00430045\U005f0046\U004f 0052\U004b0000\U0001bfff\Uf4100000\U00080040\Ue4589000\U5 334bfff\Uf4200000' . That can't be printed because of a conversion to ASCII error. If I remember correctly this is what was returning the string "ERROR" (or however it was formatted). There is also the ``Error: (-1402, 'Fork name parameter is bad'`` from the failed tests. And here is the info you wanted, Jack: 1. My build has the settings --with-pydebug --prefix=$HOME/ cvs_code --enable-ipv6 --enable-unicode=ucs4 ; so it's a straight build. 2. I think so. I also have an OS 9 partition that came with my iBook that I never touch. 3. Nope, no stray TESTFN files. The only file I have in my CVS directory that is not in the repository is Lib/plat-mac/ errors.rsrc.df.rsrc . Hope that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 08:22 Message: Logged In: YES user_id=45365 Brett, please try the following: >>> import Carbon.File >>> Carbon.File.FSGetResourceForkName() u'RESOURCE_FORK' >>> You mention it prints ERROR for you, I'd like to see exactly what it prints (u"ERROR"? "ERROR"? ERROR?). And a bit more information I need to try and duplicate the problem: 1. Are you using a framework build or a straight build? 2. Is your /Users/drifty directory in yoor root partition? 3. Could you check that there are no test_support.TESTFN or test_support.TESTFN + '2' turds on your system? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-21 23:48 Message: Logged In: YES user_id=357491 Tested and still fails with a CVS update on 2003-07-21. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-19 17:30 Message: Logged In: YES user_id=45365 This seems to be fixed in 2.3c1. Could you please test? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 11:03 Message: Logged In: YES user_id=357491 OK, so the problem seems to be coming from Mac/Modules/file/ _Filemodule.c and the File_FSGetResourceForkName function (printing the result just prints "ERROR"). The online docs for FSGetResourceForkName (which is pretty much all that is called in that function) can be found at http://developer.apple.com/ documentation/Carbon/Reference/File_Manager/file_manager/ function_group_20.html#//apple_ref/c/func/ FSGetResourceForkName . Now it looks like the error is an OS X error and has nothing to do with Python. The error (-1402) means that the fork name is syntactically invalid. I don't see how this can mean anything, though, since FSGetResourceForkName's only argument is a pointer to store the result of the call into. The only thing I can think of that might be causing this error from Python's side is that a resource fork does not exist when the call is made. But this is just a guess so I could be wrong. Jack, I am going to be gone from July 13 until July 21, so if you need any debugging info from me before 2.3 final goes out I am afraid it will have to happen soon. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:42 Message: Logged In: YES user_id=357491 OK, Jack, here is your info: - 10.2.6 - Python 2.3b2+ straight from CVS (only way to code =) - HFS+ I believe (Finder says my HD is Mac OS Extended) Ran the test from my CVS tree with my installed version of Python 2.3b2+ (I can't do anything the standard way). I just ran it with the installed copy from the installed test directory and got the errors. I also just ran it with the compiled copy but not installed Python executable in my CVS tree and once again got the error. I noticed this came up, for me at least, when I was checking a patch for posixpath.py (which was applied to CVS). I checked the code, though, and didn't find a problem where anything changed to posixpath.py would affect it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 04:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply@sourceforge.net Tue Jul 22 20:32:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 12:32:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-774751 ] slow socket binding & netinfo lookups Message-ID: Bugs item #774751, was opened at 2003-07-21 01:57 Message generated for change (Comment added) made by jvr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: Postponed Priority: 5 Submitted By: Stuart Bishop (zenzen) >Assigned to: Nobody/Anonymous (nobody) Summary: slow socket binding & netinfo lookups Initial Comment: The following code takes < 1 second to run under Python 2.1, but 20 seconds to run under Python 2.2 or 2.3 on a top- end PowerBook running OSX 10.2. It is part of the Zope startup routine. def max_server_sockets(): sl = [] while 1: try: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) s.listen(5) sl.append (s) except: break num = len(sl) for s in sl: s.close() del sl return num ---------------------------------------------------------------------- >Comment By: Just van Rossum (jvr) Date: 2003-07-22 21:32 Message: Logged In: YES user_id=92689 Why on earth was this assigned to me? I have nothing to do with the slowness in 2.2, I fixed a thread issue for 2.3, and that was already more than I intended. I know nothing about getaddrinfo. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 16:27 Message: Logged In: YES user_id=12800 Apple also said getaddrinfo has been "thread safe for a while", right? It sounds to me like our approach should be to write the code as if it were and as if it were fast, and assume Apple has/will get their act together on this. Agreed that we should do nothing here for Python 2.3. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-22 16:08 Message: Logged In: YES user_id=44345 Putting this on the back burner for now and assigning to Just as a present for when he returns ;-). I haven't been able to resolve the problem and Apple tells me that getaddrinfo was completely rewritten for 10.3 (Panther). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-22 04:48 Message: Logged In: YES user_id=44345 Another little observation. I ran the getaddr program (with the loop cranked up to 10 million iterations) while the top command was running. The lookupd process didn't show on the radar at all. While running the Python script however, lookupd consumed about 50% of the cpu. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-22 04:42 Message: Logged In: YES user_id=44345 I think we've concluded that it's okay to ship 2.3 with this problem unresolved, however I'm completely befuddled at the moment. I wrote this simple program: #include #include #include #include #include int main(int argc, char **argv) { int i; struct addrinfo hints, *res; int error; struct timeval t, u; hints.ai_family = AF_INET; hints.ai_socktype = SOCK_DGRAM; /*dummy*/ hints.ai_flags = AI_PASSIVE; printf("start\n"); for (i=0; i<100; i++) { gettimeofday(&t, NULL); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, NULL); fprintf(stderr, "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); freeaddrinfo(res); } printf("finish\n"); } When run on my Mac, it takes between 2 and 7 microseconds per getaddrinfo call. The exact same instrumented call inside socketmodule.c:setipaddr at line 700 takes about 150 *milli*seconds per call. I tried eliminating the Py_{BEGIN,END}_ALLOW_THREADS calls as well as the ACQUIRE and RELEASE of the getaddrinfo lock. That had no effect on the call. I also tweaked the compile like to run just the C preprocessor (gcc -E instead of gcc -g) and checked the output: ... hints.ai_family = af; hints.ai_socktype = 2; hints.ai_flags = 0x00000001; { PyThreadState *_save; _save = PyEval_SaveThread(); PyThread_acquire_lock(netdb_lock, 1); gettimeofday(&t, 0); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, 0); fprintf((&__sF[2]), "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); PyEval_RestoreThread(_save); } ... otool -L run against both the test program and _socket.so indicate that both refer to just one shared library (/usr/lib/libSystem.B.dylib), so both should be calling the same routine. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 22:52 Message: Logged In: YES user_id=45365 I have absolutely nothing to contribute wrt. this bug. As Just is away I guess Skip is the best target for the hot patato. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 18:33 Message: Logged In: YES user_id=44345 Digging a bit deeper, it appears on Mac OS X that fake_getaddrinfo is used. That's deemed not to be thread-safe. I see three static or global variables acessed by this function: firsttime - simple guard translate - set inside the guard - readonly after that faith_prefix - same Why not push the guard and initialization code into init_socket and protect it with the getaddrinfo lock? Fake_getaddrinfo would thus be thread-safe and could be accessed without acquiring a lock. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 18:14 Message: Logged In: YES user_id=44345 whoops... my apologies for not posting here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 17:50 Message: Logged In: YES user_id=31435 Attaching copious info from Skip Montanaro (skip.txt). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-21 09:05 Message: Logged In: YES user_id=29957 Is this something that should be looked at for 2.3rc2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 From noreply@sourceforge.net Tue Jul 22 20:35:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 12:35:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-763708 ] Failures in test_macostools for --enable-unicode=ucs4 Message-ID: Bugs item #763708, was opened at 2003-07-01 08:54 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open >Resolution: Later >Priority: 4 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) >Summary: Failures in test_macostools for --enable-unicode=ucs4 Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 21:35 Message: Logged In: YES user_id=45365 Boo, hiss! :-) You're using --enable-unicode=ucs4 and you didn't tell me that when there's a unicode problem:-) My guess is that I'm somewhere grabbing the pointer from the Python unicode object and passing that straight to the Apple routines, which will fail miserably because they expect ucs2 (or utf16, or whatever it's called). Actually, I wouldn't be surprised if there are more places where I do that. Yes, looking at the data returned this looks like a very likely scenario. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 20:42 Message: Logged In: YES user_id=357491 The Carbon.File.FSGetResourceForkName() returns u'\U00520045\U0053004f\U00550052\U00430045\U005f0046\U004f 0052\U004b0000\U0001bfff\Uf4100000\U00080040\Ue4589000\U5 334bfff\Uf4200000' . That can't be printed because of a conversion to ASCII error. If I remember correctly this is what was returning the string "ERROR" (or however it was formatted). There is also the ``Error: (-1402, 'Fork name parameter is bad'`` from the failed tests. And here is the info you wanted, Jack: 1. My build has the settings --with-pydebug --prefix=$HOME/ cvs_code --enable-ipv6 --enable-unicode=ucs4 ; so it's a straight build. 2. I think so. I also have an OS 9 partition that came with my iBook that I never touch. 3. Nope, no stray TESTFN files. The only file I have in my CVS directory that is not in the repository is Lib/plat-mac/ errors.rsrc.df.rsrc . Hope that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 17:22 Message: Logged In: YES user_id=45365 Brett, please try the following: >>> import Carbon.File >>> Carbon.File.FSGetResourceForkName() u'RESOURCE_FORK' >>> You mention it prints ERROR for you, I'd like to see exactly what it prints (u"ERROR"? "ERROR"? ERROR?). And a bit more information I need to try and duplicate the problem: 1. Are you using a framework build or a straight build? 2. Is your /Users/drifty directory in yoor root partition? 3. Could you check that there are no test_support.TESTFN or test_support.TESTFN + '2' turds on your system? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 08:48 Message: Logged In: YES user_id=357491 Tested and still fails with a CVS update on 2003-07-21. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-20 02:30 Message: Logged In: YES user_id=45365 This seems to be fixed in 2.3c1. Could you please test? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 20:03 Message: Logged In: YES user_id=357491 OK, so the problem seems to be coming from Mac/Modules/file/ _Filemodule.c and the File_FSGetResourceForkName function (printing the result just prints "ERROR"). The online docs for FSGetResourceForkName (which is pretty much all that is called in that function) can be found at http://developer.apple.com/ documentation/Carbon/Reference/File_Manager/file_manager/ function_group_20.html#//apple_ref/c/func/ FSGetResourceForkName . Now it looks like the error is an OS X error and has nothing to do with Python. The error (-1402) means that the fork name is syntactically invalid. I don't see how this can mean anything, though, since FSGetResourceForkName's only argument is a pointer to store the result of the call into. The only thing I can think of that might be causing this error from Python's side is that a resource fork does not exist when the call is made. But this is just a guess so I could be wrong. Jack, I am going to be gone from July 13 until July 21, so if you need any debugging info from me before 2.3 final goes out I am afraid it will have to happen soon. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 22:42 Message: Logged In: YES user_id=357491 OK, Jack, here is your info: - 10.2.6 - Python 2.3b2+ straight from CVS (only way to code =) - HFS+ I believe (Finder says my HD is Mac OS Extended) Ran the test from my CVS tree with my installed version of Python 2.3b2+ (I can't do anything the standard way). I just ran it with the installed copy from the installed test directory and got the errors. I also just ran it with the compiled copy but not installed Python executable in my CVS tree and once again got the error. I noticed this came up, for me at least, when I was checking a patch for posixpath.py (which was applied to CVS). I checked the code, though, and didn't find a problem where anything changed to posixpath.py would affect it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 13:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply@sourceforge.net Tue Jul 22 20:43:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 12:43:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-775836 ] change 0,1 to False,True in dict.has_key doc Message-ID: Bugs item #775836, was opened at 2003-07-22 13:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775836&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: change 0,1 to False,True in dict.has_key doc Initial Comment: http://python.org/doc/2.3c1/lib/typesmapping.html says in the table a.has_key(k) | 1 if a has a key k, else 0 Under Python 2.3 this is True / False >>> {1:2}.has_key(1) True >>> {1:2}.has_key(2) False >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775836&group_id=5470 From noreply@sourceforge.net Tue Jul 22 21:05:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 13:05:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-774751 ] slow socket binding & netinfo lookups Message-ID: Bugs item #774751, was opened at 2003-07-20 18:57 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: Postponed Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: slow socket binding & netinfo lookups Initial Comment: The following code takes < 1 second to run under Python 2.1, but 20 seconds to run under Python 2.2 or 2.3 on a top- end PowerBook running OSX 10.2. It is part of the Zope startup routine. def max_server_sockets(): sl = [] while 1: try: s = socket.socket (socket.AF_INET, socket.SOCK_STREAM) s.bind (('',0)) s.listen(5) sl.append (s) except: break num = len(sl) for s in sl: s.close() del sl return num ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-22 15:05 Message: Logged In: YES user_id=44345 I assigned it to you at least in part because your footprints were in the vicinity of the slow call. We've decided to just let it drop until after the release, so feel free to unassign it or direct it back to me. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-07-22 14:32 Message: Logged In: YES user_id=92689 Why on earth was this assigned to me? I have nothing to do with the slowness in 2.2, I fixed a thread issue for 2.3, and that was already more than I intended. I know nothing about getaddrinfo. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 09:27 Message: Logged In: YES user_id=12800 Apple also said getaddrinfo has been "thread safe for a while", right? It sounds to me like our approach should be to write the code as if it were and as if it were fast, and assume Apple has/will get their act together on this. Agreed that we should do nothing here for Python 2.3. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-22 09:08 Message: Logged In: YES user_id=44345 Putting this on the back burner for now and assigning to Just as a present for when he returns ;-). I haven't been able to resolve the problem and Apple tells me that getaddrinfo was completely rewritten for 10.3 (Panther). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 21:48 Message: Logged In: YES user_id=44345 Another little observation. I ran the getaddr program (with the loop cranked up to 10 million iterations) while the top command was running. The lookupd process didn't show on the radar at all. While running the Python script however, lookupd consumed about 50% of the cpu. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 21:42 Message: Logged In: YES user_id=44345 I think we've concluded that it's okay to ship 2.3 with this problem unresolved, however I'm completely befuddled at the moment. I wrote this simple program: #include #include #include #include #include int main(int argc, char **argv) { int i; struct addrinfo hints, *res; int error; struct timeval t, u; hints.ai_family = AF_INET; hints.ai_socktype = SOCK_DGRAM; /*dummy*/ hints.ai_flags = AI_PASSIVE; printf("start\n"); for (i=0; i<100; i++) { gettimeofday(&t, NULL); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, NULL); fprintf(stderr, "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); freeaddrinfo(res); } printf("finish\n"); } When run on my Mac, it takes between 2 and 7 microseconds per getaddrinfo call. The exact same instrumented call inside socketmodule.c:setipaddr at line 700 takes about 150 *milli*seconds per call. I tried eliminating the Py_{BEGIN,END}_ALLOW_THREADS calls as well as the ACQUIRE and RELEASE of the getaddrinfo lock. That had no effect on the call. I also tweaked the compile like to run just the C preprocessor (gcc -E instead of gcc -g) and checked the output: ... hints.ai_family = af; hints.ai_socktype = 2; hints.ai_flags = 0x00000001; { PyThreadState *_save; _save = PyEval_SaveThread(); PyThread_acquire_lock(netdb_lock, 1); gettimeofday(&t, 0); error = getaddrinfo(0, "0", &hints, &res); gettimeofday(&u, 0); fprintf((&__sF[2]), "gtod: %.6f\n", u.tv_sec-t.tv_sec+(u.tv_usec-t.tv_usec)*1e-6); PyEval_RestoreThread(_save); } ... otool -L run against both the test program and _socket.so indicate that both refer to just one shared library (/usr/lib/libSystem.B.dylib), so both should be calling the same routine. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 15:52 Message: Logged In: YES user_id=45365 I have absolutely nothing to contribute wrt. this bug. As Just is away I guess Skip is the best target for the hot patato. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 11:33 Message: Logged In: YES user_id=44345 Digging a bit deeper, it appears on Mac OS X that fake_getaddrinfo is used. That's deemed not to be thread-safe. I see three static or global variables acessed by this function: firsttime - simple guard translate - set inside the guard - readonly after that faith_prefix - same Why not push the guard and initialization code into init_socket and protect it with the getaddrinfo lock? Fake_getaddrinfo would thus be thread-safe and could be accessed without acquiring a lock. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-21 11:14 Message: Logged In: YES user_id=44345 whoops... my apologies for not posting here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 10:50 Message: Logged In: YES user_id=31435 Attaching copious info from Skip Montanaro (skip.txt). ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-21 02:05 Message: Logged In: YES user_id=29957 Is this something that should be looked at for 2.3rc2? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774751&group_id=5470 From noreply@sourceforge.net Tue Jul 22 21:13:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 13:13:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-775836 ] change 0,1 to False,True in dict.has_key doc Message-ID: Bugs item #775836, was opened at 2003-07-22 15:43 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775836&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: change 0,1 to False,True in dict.has_key doc Initial Comment: http://python.org/doc/2.3c1/lib/typesmapping.html says in the table a.has_key(k) | 1 if a has a key k, else 0 Under Python 2.3 this is True / False >>> {1:2}.has_key(1) True >>> {1:2}.has_key(2) False >>> ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-22 16:13 Message: Logged In: YES user_id=33168 Fred, not sure if this should be fixed for 2.3 or wait. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775836&group_id=5470 From noreply@sourceforge.net Tue Jul 22 21:16:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 13:16:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-775836 ] change 0,1 to False,True in dict.has_key doc Message-ID: Bugs item #775836, was opened at 2003-07-22 15:43 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775836&group_id=5470 Category: Documentation >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: change 0,1 to False,True in dict.has_key doc Initial Comment: http://python.org/doc/2.3c1/lib/typesmapping.html says in the table a.has_key(k) | 1 if a has a key k, else 0 Under Python 2.3 this is True / False >>> {1:2}.has_key(1) True >>> {1:2}.has_key(2) False >>> ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-22 16:16 Message: Logged In: YES user_id=3066 It'll have to wait for 2.3.1/2.4. We've done (more than) enough at this point. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-22 16:13 Message: Logged In: YES user_id=33168 Fred, not sure if this should be fixed for 2.3 or wait. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775836&group_id=5470 From noreply@sourceforge.net Tue Jul 22 21:21:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 13:21:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 20: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=775850&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Tue Jul 22 21:28:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 13:28:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 20:21 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 20:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Tue Jul 22 21:40:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 13:40:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 16:21 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 16:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 16:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Tue Jul 22 21:41:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 13:41:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 22:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 22:41 Message: Logged In: YES user_id=21627 Please collect the following information: 1. Invoke the linker line with -Wl,--verbose (manually), to find out the path it uses for the -ldb-4.1 command line option. In particular, find out whether it uses a shared or static library (.so or .a) 2. Perform nm on that library|grep db_create The symbol really should be there; it is on all copies of -ldb-something that I can get hold of. If it is not in your copy, you somehow messed up the BerkeleyDB build. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 22:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 22:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Tue Jul 22 21:45:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 13:45:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Raymond Hettinger (rhettinger) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 22:45 Message: Logged In: YES user_id=21627 I cannot reproduce the problem, with Windows ME German edition, ActivePython 2.2.1, and Python 2.3b2. In particular, the file opens just fine in step 15, and hence I cannot execute step 16. Step 19 succeeds with saving the file. Can you please attach the three files, preferably as a single ZIP file (see Check to Upload and Attach a File below)? Can you also report what sys.getdefaultencoding() is in your two installations? ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:15 Message: Logged In: YES user_id=624347 Sorry, but there is at least a mistake in my previous message. Item 15 should be: 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py) => I think this behaviour can be an IDLE bug, too. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:10 Message: Logged In: YES user_id=624347 Let's start from the beginning: 1. I uninstall Python from my system (Windows 98 SE Spanish) In my autoexec.bat I can read mode con codepage prepare=((850)C:\WINDOWS\COMMAND\ega.cpi) mode con codepage select=850 keyb sp,,C:\WINDOWS\COMMAND\keyboard.sys 2. I install Python 2.2.3 3. I open IDLE 0.8 4. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 5. If I try to save this file as test01.py, I get the following IDLE message Exception in Tkinter callback Traceback (most recent call last): File "C:\ARCHIVOS DE PROGRAMA\PYTHON223\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 126, in save self.save_as(event) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 136, in save_as if self.writefile(filename): File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 151, in writefile chars = str(self.text.get("1.0", "end-1c")) UnicodeError: ASCII encoding error: ordinal not in range(128) 6. I add the following sitecustomize.py file to lib/site-packages: # Set the string encoding used by the Unicode implementation. # The default is 'ascii' encoding = "ascii" # <= CHANGE THIS if you wish # Enable to support locale aware default string encodings. import locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1] print encoding if encoding != "ascii": import sys sys.setdefaultencoding(encoding) 7. I close IDLE 0.8 (without saving test01.py) 8. I open again IDLE 0.8 9. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 10. I save the file as test01.py (no messages, no warnings) 11. I close IDLE 0.8 12. I open IDLE 0.8. I load test01.py and run it. Everything is OK. 13. I uninstall Python 2.2.3 and install Python 2.3rc1 14. I open IDLE 1.0rc1 and open test01.py. That is what I see print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters => I think this behaviour can be an IDLE bug. 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. 16 I delete non-ASCII characters. The program is now: print "hola, mundo!" print 17. I save it as test02.py without problems. 18. I close test02.py and open it again. I add non ASCII characters. The program is now: print "¡hola, mundo!" print "áéíóú" 19. I try to save it as test03.py. IDLE shows me the warning message "Non-ASCII found, yet no encoding declared". I click in "Edit my file". The program is now: # -*- coding: cp1252 -*- print "¡hola, mundo!" print "áéíóú" I try to save it again as test03.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test02.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. I am sending attached the test01.py file. By the way, IDLE creates a .idlerc folder (with a recent-files.lst file in it) in the folder where I have created test02.py file. Is it normal? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 09:02 Message: Logged In: YES user_id=80475 I'll continue to work on this one to see if I can use the debugger to isolate the problem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 01:28 Message: Logged In: YES user_id=80475 If Bartolomé is having the same issue I had (on Py2.3b2, but disappeared on PY2.3c1), then the symptoms were: Open Doc/tut/tut.tex Make minor edits Observe: - the stars by the filename show a need for a save - the editor window shows the changes Save (using Cntl-S, File Save, or FileSaveAs) Observe: - no windows pop-up refusing to save - the stars remain - the syntax highlighting indicates that no valid python syntax was found Exit IDLE - get prompted to save and say YES - the exit occurs Look at the file - note that the changes did not take For a brief while, I could re-create this reliably. No one else has been able to reproduce (leading me to think this was specific to WinMe). I could also reproduce it on small files and files like "c:\a.tmp" (leading me to think it was independent of o.s. pathnaming conventions). For a while, I could also reproduce it on a fresh build, but that stopped as soon that the last release candidate changes went in. Sorry for the circuituous report, but if I knew what it was, it would be fixed already. Also, since no one else could reproduce it, I was beginning to suspect my own machine. If Bartolomé is having save problems without getting a warning window then, he is having the same issue. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-21 01:05 Message: Logged In: YES user_id=21627 rhettinger: In IDLE 1.0, IDLE should not ever refuse to safe the file, unless the declared encoding (through the coding: declaration) cannot support the characters in the file. barto: I still don't understand what you did, either in case a) or case b). Can you give precise data? For a), please report what specific encoding you have put into sitecustomize.py, what code page your windows installation uses, and please attach a file that you have created with IDLE 0.8. For b), what do you mean by "save does not work"? Was there some error message? If so, what did it say? If not, what else was wrong. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 00:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 00:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Tue Jul 22 21:59:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 13:59:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-775878 ] PythonLauncher has empty popup for interpreters Message-ID: Bugs item #775878, was opened at 2003-07-22 22: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=775878&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: PythonLauncher has empty popup for interpreters Initial Comment: The PythonLauncher preferences window has a popup which allows you to select the interpreter to use for the various file types. This popup is empty, however. The default is set, though, so this isn't a critical error. Discovered on Panther, so it could be a problem there only. But I vaguely remember that I never actually wrote the code:-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775878&group_id=5470 From noreply@sourceforge.net Tue Jul 22 22:02:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 14:02:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 20:21 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 21:02 Message: Logged In: YES user_id=52562 Okay, I've tried these. -Wl,verbose tells me, as I expected: attempt to open /usr/local/stow/python-g/lib/libdb-4.1.so failed attempt to open /usr/local/stow/python-g/lib/libdb-4.1.a failed attempt to open /usr/local/lib/libdb-4.1.so succeeded -ldb-4.1 (/usr/local/lib/libdb-4.1.so) nm tells me, as expected, that db_create is present: MAIL pion:~$ nm /usr/local/lib/libdb-4.1.so | grep db_create 0001a554 T __bam_db_create 000783cc T __ham_db_create 000a5fe0 T __qam_db_create 000492c8 T db_create Adding /usr/local/lib to my /etc/ld.so.conf and running ldconfig *did* fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 20:41 Message: Logged In: YES user_id=21627 Please collect the following information: 1. Invoke the linker line with -Wl,--verbose (manually), to find out the path it uses for the -ldb-4.1 command line option. In particular, find out whether it uses a shared or static library (.so or .a) 2. Perform nm on that library|grep db_create The symbol really should be there; it is on all copies of -ldb-something that I can get hold of. If it is not in your copy, you somehow messed up the BerkeleyDB build. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 20:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 20:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Tue Jul 22 22:04:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 14:04:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-775836 ] change 0,1 to False,True in dict.has_key doc Message-ID: Bugs item #775836, was opened at 2003-07-22 14:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775836&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) >Assigned to: Raymond Hettinger (rhettinger) Summary: change 0,1 to False,True in dict.has_key doc Initial Comment: http://python.org/doc/2.3c1/lib/typesmapping.html says in the table a.has_key(k) | 1 if a has a key k, else 0 Under Python 2.3 this is True / False >>> {1:2}.has_key(1) True >>> {1:2}.has_key(2) False >>> ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-22 16:04 Message: Logged In: YES user_id=80475 I'll fix it after Py2.3 is done. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-22 15:16 Message: Logged In: YES user_id=3066 It'll have to wait for 2.3.1/2.4. We've done (more than) enough at this point. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-22 15:13 Message: Logged In: YES user_id=33168 Fred, not sure if this should be fixed for 2.3 or wait. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775836&group_id=5470 From noreply@sourceforge.net Tue Jul 22 22:05:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 14:05:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 22:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 23:05 Message: Logged In: YES user_id=21627 Ok. Can you try to find out why distutils fails to use the -R/-rpath option? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 23:02 Message: Logged In: YES user_id=52562 Okay, I've tried these. -Wl,verbose tells me, as I expected: attempt to open /usr/local/stow/python-g/lib/libdb-4.1.so failed attempt to open /usr/local/stow/python-g/lib/libdb-4.1.a failed attempt to open /usr/local/lib/libdb-4.1.so succeeded -ldb-4.1 (/usr/local/lib/libdb-4.1.so) nm tells me, as expected, that db_create is present: MAIL pion:~$ nm /usr/local/lib/libdb-4.1.so | grep db_create 0001a554 T __bam_db_create 000783cc T __ham_db_create 000a5fe0 T __qam_db_create 000492c8 T db_create Adding /usr/local/lib to my /etc/ld.so.conf and running ldconfig *did* fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 22:41 Message: Logged In: YES user_id=21627 Please collect the following information: 1. Invoke the linker line with -Wl,--verbose (manually), to find out the path it uses for the -ldb-4.1 command line option. In particular, find out whether it uses a shared or static library (.so or .a) 2. Perform nm on that library|grep db_create The symbol really should be there; it is on all copies of -ldb-something that I can get hold of. If it is not in your copy, you somehow messed up the BerkeleyDB build. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 22:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 22:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Tue Jul 22 22:16:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 14:16:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-775892 ] test_coercion failing on Panther Message-ID: Bugs item #775892, was opened at 2003-07-22 23: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=775892&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_coercion failing on Panther Initial Comment: Test_coercion is failing on Panther. All the failures have the same form: the output is (XXX-0j) in stead of the expected (XXX+0j). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775892&group_id=5470 From noreply@sourceforge.net Tue Jul 22 22:29:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 14:29:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-775892 ] test_coercion failing on Panther Message-ID: Bugs item #775892, was opened at 2003-07-22 17:16 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775892&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_coercion failing on Panther Initial Comment: Test_coercion is failing on Panther. All the failures have the same form: the output is (XXX-0j) in stead of the expected (XXX+0j). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-22 17:29 Message: Logged In: YES user_id=31435 Ignore it -- the sign of a float 0 is more accidental than not. If the compiler has a switch to disable generation of fused multiply-add instructions, the failure will probably go away. After 2.3, we should rewrite the test so that "sign of 0" cases aren't even tried anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775892&group_id=5470 From noreply@sourceforge.net Tue Jul 22 22:27:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 14:27:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-763708 ] Failures in test_macostools for --enable-unicode=ucs4 Message-ID: Bugs item #763708, was opened at 2003-06-30 23:54 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: Later Priority: 4 Submitted By: Brett Cannon (bcannon) Assigned to: Jack Jansen (jackjansen) Summary: Failures in test_macostools for --enable-unicode=ucs4 Initial Comment: Here are the test results: test_copy (__main__.TestMacostools) ... ok test_mkalias (__main__.TestMacostools) ... ERROR test_mkalias_relative (__main__.TestMacostools) ... ERROR test_touched (__main__.TestMacostools) ... ok ===================================== ================================= ERROR: test_mkalias (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 69, in test_mkalias macostools.mkalias(test_support.TESTFN, TESTFN2) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ===================================== ================================= ERROR: test_mkalias_relative (__main__.TestMacostools) -------------------------------------------------------------------- -- Traceback (most recent call last): File "Lib/test/test_macostools.py", line 78, in test_mkalias_relative macostools.mkalias(test_support.TESTFN, TESTFN2, sys.prefix) File "/Users/drifty/cvs_code/lib/python2.3/plat-mac/ macostools.py", line 46, in mkalias File.FSGetResourceForkName()) Error: (-1402, 'Fork name parameter is bad') ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-22 14:27 Message: Logged In: YES user_id=357491 Sorry, Jack. I didn't know that this was a Unicode issue. Oh well, at least the cause has been narrowed down. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 12:35 Message: Logged In: YES user_id=45365 Boo, hiss! :-) You're using --enable-unicode=ucs4 and you didn't tell me that when there's a unicode problem:-) My guess is that I'm somewhere grabbing the pointer from the Python unicode object and passing that straight to the Apple routines, which will fail miserably because they expect ucs2 (or utf16, or whatever it's called). Actually, I wouldn't be surprised if there are more places where I do that. Yes, looking at the data returned this looks like a very likely scenario. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-22 11:42 Message: Logged In: YES user_id=357491 The Carbon.File.FSGetResourceForkName() returns u'\U00520045\U0053004f\U00550052\U00430045\U005f0046\U004f 0052\U004b0000\U0001bfff\Uf4100000\U00080040\Ue4589000\U5 334bfff\Uf4200000' . That can't be printed because of a conversion to ASCII error. If I remember correctly this is what was returning the string "ERROR" (or however it was formatted). There is also the ``Error: (-1402, 'Fork name parameter is bad'`` from the failed tests. And here is the info you wanted, Jack: 1. My build has the settings --with-pydebug --prefix=$HOME/ cvs_code --enable-ipv6 --enable-unicode=ucs4 ; so it's a straight build. 2. I think so. I also have an OS 9 partition that came with my iBook that I never touch. 3. Nope, no stray TESTFN files. The only file I have in my CVS directory that is not in the repository is Lib/plat-mac/ errors.rsrc.df.rsrc . Hope that helps. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 08:22 Message: Logged In: YES user_id=45365 Brett, please try the following: >>> import Carbon.File >>> Carbon.File.FSGetResourceForkName() u'RESOURCE_FORK' >>> You mention it prints ERROR for you, I'd like to see exactly what it prints (u"ERROR"? "ERROR"? ERROR?). And a bit more information I need to try and duplicate the problem: 1. Are you using a framework build or a straight build? 2. Is your /Users/drifty directory in yoor root partition? 3. Could you check that there are no test_support.TESTFN or test_support.TESTFN + '2' turds on your system? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-21 23:48 Message: Logged In: YES user_id=357491 Tested and still fails with a CVS update on 2003-07-21. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-19 17:30 Message: Logged In: YES user_id=45365 This seems to be fixed in 2.3c1. Could you please test? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 11:03 Message: Logged In: YES user_id=357491 OK, so the problem seems to be coming from Mac/Modules/file/ _Filemodule.c and the File_FSGetResourceForkName function (printing the result just prints "ERROR"). The online docs for FSGetResourceForkName (which is pretty much all that is called in that function) can be found at http://developer.apple.com/ documentation/Carbon/Reference/File_Manager/file_manager/ function_group_20.html#//apple_ref/c/func/ FSGetResourceForkName . Now it looks like the error is an OS X error and has nothing to do with Python. The error (-1402) means that the fork name is syntactically invalid. I don't see how this can mean anything, though, since FSGetResourceForkName's only argument is a pointer to store the result of the call into. The only thing I can think of that might be causing this error from Python's side is that a resource fork does not exist when the call is made. But this is just a guess so I could be wrong. Jack, I am going to be gone from July 13 until July 21, so if you need any debugging info from me before 2.3 final goes out I am afraid it will have to happen soon. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 13:42 Message: Logged In: YES user_id=357491 OK, Jack, here is your info: - 10.2.6 - Python 2.3b2+ straight from CVS (only way to code =) - HFS+ I believe (Finder says my HD is Mac OS Extended) Ran the test from my CVS tree with my installed version of Python 2.3b2+ (I can't do anything the standard way). I just ran it with the installed copy from the installed test directory and got the errors. I also just ran it with the compiled copy but not installed Python executable in my CVS tree and once again got the error. I noticed this came up, for me at least, when I was checking a patch for posixpath.py (which was applied to CVS). I checked the code, though, and didn't find a problem where anything changed to posixpath.py would affect it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-01 04:47 Message: Logged In: YES user_id=45365 Brett, I've seen this bug once in a while, but whenever I try to hunt it it disappears. Could you give me the following info: - OSX exact version - Python exact version, plus where you got it from (binary install, source tarball install, CVS) - Type of filesystem (HFS+, UFS, NFS, something else) Also, if you're building from source, did you run the tests from the build tree or from the installed tree? Could you try the other one too? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470 From noreply@sourceforge.net Tue Jul 22 22:40:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 14:40:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22:23 Message generated for change (Comment added) made by barto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Raymond Hettinger (rhettinger) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-22 23:40 Message: Logged In: YES user_id=624347 1. I have added getdefaultencoding() to test_01.py: from sys import * print getdefaultencoding() print "¡hola, mundo!" print "áéíóú" In Python 2.2.3 (IDLE 0.8) the ouput of the program is now: cp1252 ¡hola, mundo! áéíóú (as expected) 2. In Python 2.3rc1 (IDLE 1.0rc1) the output of test_01.py is: ascii ¡hola, mundo! áéíóú But I can not save it as test_02.py (as I have explained in my previous post). 3. I delete the non-ASCII characters. test_02.py is now: from sys import * print getdefaultencoding() print "hola, mundo!" print Now I can save it in IDLE 1.0rc1 and the output is: ascii hola, mundo! 4. In IDLE 1.0rc1 I add non-ASCII characters. The program is now: from sys import * print getdefaultencoding() print "¡hola, mundo!" print "áéíóú" But I can not save it as test_03.py (as I have explained in my previous post). 5. I am sending attached test_01.py and test_02.py in a zip file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 22:45 Message: Logged In: YES user_id=21627 I cannot reproduce the problem, with Windows ME German edition, ActivePython 2.2.1, and Python 2.3b2. In particular, the file opens just fine in step 15, and hence I cannot execute step 16. Step 19 succeeds with saving the file. Can you please attach the three files, preferably as a single ZIP file (see Check to Upload and Attach a File below)? Can you also report what sys.getdefaultencoding() is in your two installations? ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:15 Message: Logged In: YES user_id=624347 Sorry, but there is at least a mistake in my previous message. Item 15 should be: 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py) => I think this behaviour can be an IDLE bug, too. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:10 Message: Logged In: YES user_id=624347 Let's start from the beginning: 1. I uninstall Python from my system (Windows 98 SE Spanish) In my autoexec.bat I can read mode con codepage prepare=((850)C:\WINDOWS\COMMAND\ega.cpi) mode con codepage select=850 keyb sp,,C:\WINDOWS\COMMAND\keyboard.sys 2. I install Python 2.2.3 3. I open IDLE 0.8 4. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 5. If I try to save this file as test01.py, I get the following IDLE message Exception in Tkinter callback Traceback (most recent call last): File "C:\ARCHIVOS DE PROGRAMA\PYTHON223\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 126, in save self.save_as(event) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 136, in save_as if self.writefile(filename): File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 151, in writefile chars = str(self.text.get("1.0", "end-1c")) UnicodeError: ASCII encoding error: ordinal not in range(128) 6. I add the following sitecustomize.py file to lib/site-packages: # Set the string encoding used by the Unicode implementation. # The default is 'ascii' encoding = "ascii" # <= CHANGE THIS if you wish # Enable to support locale aware default string encodings. import locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1] print encoding if encoding != "ascii": import sys sys.setdefaultencoding(encoding) 7. I close IDLE 0.8 (without saving test01.py) 8. I open again IDLE 0.8 9. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 10. I save the file as test01.py (no messages, no warnings) 11. I close IDLE 0.8 12. I open IDLE 0.8. I load test01.py and run it. Everything is OK. 13. I uninstall Python 2.2.3 and install Python 2.3rc1 14. I open IDLE 1.0rc1 and open test01.py. That is what I see print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters => I think this behaviour can be an IDLE bug. 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. 16 I delete non-ASCII characters. The program is now: print "hola, mundo!" print 17. I save it as test02.py without problems. 18. I close test02.py and open it again. I add non ASCII characters. The program is now: print "¡hola, mundo!" print "áéíóú" 19. I try to save it as test03.py. IDLE shows me the warning message "Non-ASCII found, yet no encoding declared". I click in "Edit my file". The program is now: # -*- coding: cp1252 -*- print "¡hola, mundo!" print "áéíóú" I try to save it again as test03.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test02.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. I am sending attached the test01.py file. By the way, IDLE creates a .idlerc folder (with a recent-files.lst file in it) in the folder where I have created test02.py file. Is it normal? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 09:02 Message: Logged In: YES user_id=80475 I'll continue to work on this one to see if I can use the debugger to isolate the problem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 01:28 Message: Logged In: YES user_id=80475 If Bartolomé is having the same issue I had (on Py2.3b2, but disappeared on PY2.3c1), then the symptoms were: Open Doc/tut/tut.tex Make minor edits Observe: - the stars by the filename show a need for a save - the editor window shows the changes Save (using Cntl-S, File Save, or FileSaveAs) Observe: - no windows pop-up refusing to save - the stars remain - the syntax highlighting indicates that no valid python syntax was found Exit IDLE - get prompted to save and say YES - the exit occurs Look at the file - note that the changes did not take For a brief while, I could re-create this reliably. No one else has been able to reproduce (leading me to think this was specific to WinMe). I could also reproduce it on small files and files like "c:\a.tmp" (leading me to think it was independent of o.s. pathnaming conventions). For a while, I could also reproduce it on a fresh build, but that stopped as soon that the last release candidate changes went in. Sorry for the circuituous report, but if I knew what it was, it would be fixed already. Also, since no one else could reproduce it, I was beginning to suspect my own machine. If Bartolomé is having save problems without getting a warning window then, he is having the same issue. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-21 01:05 Message: Logged In: YES user_id=21627 rhettinger: In IDLE 1.0, IDLE should not ever refuse to safe the file, unless the declared encoding (through the coding: declaration) cannot support the characters in the file. barto: I still don't understand what you did, either in case a) or case b). Can you give precise data? For a), please report what specific encoding you have put into sitecustomize.py, what code page your windows installation uses, and please attach a file that you have created with IDLE 0.8. For b), what do you mean by "save does not work"? Was there some error message? If so, what did it say? If not, what else was wrong. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 00:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 00:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Tue Jul 22 22:45:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 14:45:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-775340 ] OSX 'freeze' bug Message-ID: Bugs item #775340, was opened at 2003-07-22 00:51 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775340&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None >Priority: 4 Submitted By: justin (justinlk) Assigned to: Nobody/Anonymous (nobody) Summary: OSX 'freeze' bug Initial Comment: When trying to 'make' a frozen script on OSX framework install, it looks for and fails to find config.o (It says: config.o frozen.o M_BaseHTTPServer.o [...] /Library/ Frameworks/Python.framework/Versions/2.3/lib/ python2.3/config/libpython.a -o Study make: config.o: Command not found make: *** [Study] Error 127) ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-22 23:45 Message: Logged In: YES user_id=45365 Freeze doesn't understand framework builds. I see a different error from what you see (somehow for me it does use "c++" to do the linking) but even then it doesn't work because there is no such beast as config/libpython.a in a framework build. If freeze also works with dynamic builds of Python it should be doable to get it to work with framework builds too. But I'm lowering the priority on this bug anyway because there is another way to get a standalone application for MacOSX: bundlebuilder.py. The bad news is the only documentation is in the source code, plus the help given when you run it with --help. Specifically, look at the --standalone option. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775340&group_id=5470 From noreply@sourceforge.net Tue Jul 22 22:53:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 14:53:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Raymond Hettinger (rhettinger) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 23:53 Message: Logged In: YES user_id=21627 I finally understand what is going on. The file test_01.py is completely corrupted. The second line is encoded in Latin-1, whereas the last line is encoded in UTF-8. There is no way IDLE 1.0 could possibly process it in a meaningful way. The problem with saving it still needs to be addressed. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-22 23:40 Message: Logged In: YES user_id=624347 1. I have added getdefaultencoding() to test_01.py: from sys import * print getdefaultencoding() print "¡hola, mundo!" print "áéíóú" In Python 2.2.3 (IDLE 0.8) the ouput of the program is now: cp1252 ¡hola, mundo! áéíóú (as expected) 2. In Python 2.3rc1 (IDLE 1.0rc1) the output of test_01.py is: ascii ¡hola, mundo! áéíóú But I can not save it as test_02.py (as I have explained in my previous post). 3. I delete the non-ASCII characters. test_02.py is now: from sys import * print getdefaultencoding() print "hola, mundo!" print Now I can save it in IDLE 1.0rc1 and the output is: ascii hola, mundo! 4. In IDLE 1.0rc1 I add non-ASCII characters. The program is now: from sys import * print getdefaultencoding() print "¡hola, mundo!" print "áéíóú" But I can not save it as test_03.py (as I have explained in my previous post). 5. I am sending attached test_01.py and test_02.py in a zip file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 22:45 Message: Logged In: YES user_id=21627 I cannot reproduce the problem, with Windows ME German edition, ActivePython 2.2.1, and Python 2.3b2. In particular, the file opens just fine in step 15, and hence I cannot execute step 16. Step 19 succeeds with saving the file. Can you please attach the three files, preferably as a single ZIP file (see Check to Upload and Attach a File below)? Can you also report what sys.getdefaultencoding() is in your two installations? ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:15 Message: Logged In: YES user_id=624347 Sorry, but there is at least a mistake in my previous message. Item 15 should be: 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py) => I think this behaviour can be an IDLE bug, too. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:10 Message: Logged In: YES user_id=624347 Let's start from the beginning: 1. I uninstall Python from my system (Windows 98 SE Spanish) In my autoexec.bat I can read mode con codepage prepare=((850)C:\WINDOWS\COMMAND\ega.cpi) mode con codepage select=850 keyb sp,,C:\WINDOWS\COMMAND\keyboard.sys 2. I install Python 2.2.3 3. I open IDLE 0.8 4. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 5. If I try to save this file as test01.py, I get the following IDLE message Exception in Tkinter callback Traceback (most recent call last): File "C:\ARCHIVOS DE PROGRAMA\PYTHON223\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 126, in save self.save_as(event) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 136, in save_as if self.writefile(filename): File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 151, in writefile chars = str(self.text.get("1.0", "end-1c")) UnicodeError: ASCII encoding error: ordinal not in range(128) 6. I add the following sitecustomize.py file to lib/site-packages: # Set the string encoding used by the Unicode implementation. # The default is 'ascii' encoding = "ascii" # <= CHANGE THIS if you wish # Enable to support locale aware default string encodings. import locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1] print encoding if encoding != "ascii": import sys sys.setdefaultencoding(encoding) 7. I close IDLE 0.8 (without saving test01.py) 8. I open again IDLE 0.8 9. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 10. I save the file as test01.py (no messages, no warnings) 11. I close IDLE 0.8 12. I open IDLE 0.8. I load test01.py and run it. Everything is OK. 13. I uninstall Python 2.2.3 and install Python 2.3rc1 14. I open IDLE 1.0rc1 and open test01.py. That is what I see print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters => I think this behaviour can be an IDLE bug. 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. 16 I delete non-ASCII characters. The program is now: print "hola, mundo!" print 17. I save it as test02.py without problems. 18. I close test02.py and open it again. I add non ASCII characters. The program is now: print "¡hola, mundo!" print "áéíóú" 19. I try to save it as test03.py. IDLE shows me the warning message "Non-ASCII found, yet no encoding declared". I click in "Edit my file". The program is now: # -*- coding: cp1252 -*- print "¡hola, mundo!" print "áéíóú" I try to save it again as test03.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test02.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. I am sending attached the test01.py file. By the way, IDLE creates a .idlerc folder (with a recent-files.lst file in it) in the folder where I have created test02.py file. Is it normal? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 09:02 Message: Logged In: YES user_id=80475 I'll continue to work on this one to see if I can use the debugger to isolate the problem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 01:28 Message: Logged In: YES user_id=80475 If Bartolomé is having the same issue I had (on Py2.3b2, but disappeared on PY2.3c1), then the symptoms were: Open Doc/tut/tut.tex Make minor edits Observe: - the stars by the filename show a need for a save - the editor window shows the changes Save (using Cntl-S, File Save, or FileSaveAs) Observe: - no windows pop-up refusing to save - the stars remain - the syntax highlighting indicates that no valid python syntax was found Exit IDLE - get prompted to save and say YES - the exit occurs Look at the file - note that the changes did not take For a brief while, I could re-create this reliably. No one else has been able to reproduce (leading me to think this was specific to WinMe). I could also reproduce it on small files and files like "c:\a.tmp" (leading me to think it was independent of o.s. pathnaming conventions). For a while, I could also reproduce it on a fresh build, but that stopped as soon that the last release candidate changes went in. Sorry for the circuituous report, but if I knew what it was, it would be fixed already. Also, since no one else could reproduce it, I was beginning to suspect my own machine. If Bartolomé is having save problems without getting a warning window then, he is having the same issue. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-21 01:05 Message: Logged In: YES user_id=21627 rhettinger: In IDLE 1.0, IDLE should not ever refuse to safe the file, unless the declared encoding (through the coding: declaration) cannot support the characters in the file. barto: I still don't understand what you did, either in case a) or case b). Can you give precise data? For a), please report what specific encoding you have put into sitecustomize.py, what code page your windows installation uses, and please attach a file that you have created with IDLE 0.8. For b), what do you mean by "save does not work"? Was there some error message? If so, what did it say? If not, what else was wrong. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 00:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 00:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Tue Jul 22 23:22:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 15:22:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22:23 Message generated for change (Comment added) made by barto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Raymond Hettinger (rhettinger) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-23 00:22 Message: Logged In: YES user_id=624347 What does it mean "completely corrupted"? IDLE 0.8 can open and execute it. Is there a way of "cleaning" it? Do you need more information from me? I will be available until Saturday the 26th of July. Best regards. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 23:53 Message: Logged In: YES user_id=21627 I finally understand what is going on. The file test_01.py is completely corrupted. The second line is encoded in Latin-1, whereas the last line is encoded in UTF-8. There is no way IDLE 1.0 could possibly process it in a meaningful way. The problem with saving it still needs to be addressed. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-22 23:40 Message: Logged In: YES user_id=624347 1. I have added getdefaultencoding() to test_01.py: from sys import * print getdefaultencoding() print "¡hola, mundo!" print "áéíóú" In Python 2.2.3 (IDLE 0.8) the ouput of the program is now: cp1252 ¡hola, mundo! áéíóú (as expected) 2. In Python 2.3rc1 (IDLE 1.0rc1) the output of test_01.py is: ascii ¡hola, mundo! áéíóú But I can not save it as test_02.py (as I have explained in my previous post). 3. I delete the non-ASCII characters. test_02.py is now: from sys import * print getdefaultencoding() print "hola, mundo!" print Now I can save it in IDLE 1.0rc1 and the output is: ascii hola, mundo! 4. In IDLE 1.0rc1 I add non-ASCII characters. The program is now: from sys import * print getdefaultencoding() print "¡hola, mundo!" print "áéíóú" But I can not save it as test_03.py (as I have explained in my previous post). 5. I am sending attached test_01.py and test_02.py in a zip file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 22:45 Message: Logged In: YES user_id=21627 I cannot reproduce the problem, with Windows ME German edition, ActivePython 2.2.1, and Python 2.3b2. In particular, the file opens just fine in step 15, and hence I cannot execute step 16. Step 19 succeeds with saving the file. Can you please attach the three files, preferably as a single ZIP file (see Check to Upload and Attach a File below)? Can you also report what sys.getdefaultencoding() is in your two installations? ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:15 Message: Logged In: YES user_id=624347 Sorry, but there is at least a mistake in my previous message. Item 15 should be: 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py) => I think this behaviour can be an IDLE bug, too. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:10 Message: Logged In: YES user_id=624347 Let's start from the beginning: 1. I uninstall Python from my system (Windows 98 SE Spanish) In my autoexec.bat I can read mode con codepage prepare=((850)C:\WINDOWS\COMMAND\ega.cpi) mode con codepage select=850 keyb sp,,C:\WINDOWS\COMMAND\keyboard.sys 2. I install Python 2.2.3 3. I open IDLE 0.8 4. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 5. If I try to save this file as test01.py, I get the following IDLE message Exception in Tkinter callback Traceback (most recent call last): File "C:\ARCHIVOS DE PROGRAMA\PYTHON223\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 126, in save self.save_as(event) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 136, in save_as if self.writefile(filename): File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 151, in writefile chars = str(self.text.get("1.0", "end-1c")) UnicodeError: ASCII encoding error: ordinal not in range(128) 6. I add the following sitecustomize.py file to lib/site-packages: # Set the string encoding used by the Unicode implementation. # The default is 'ascii' encoding = "ascii" # <= CHANGE THIS if you wish # Enable to support locale aware default string encodings. import locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1] print encoding if encoding != "ascii": import sys sys.setdefaultencoding(encoding) 7. I close IDLE 0.8 (without saving test01.py) 8. I open again IDLE 0.8 9. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 10. I save the file as test01.py (no messages, no warnings) 11. I close IDLE 0.8 12. I open IDLE 0.8. I load test01.py and run it. Everything is OK. 13. I uninstall Python 2.2.3 and install Python 2.3rc1 14. I open IDLE 1.0rc1 and open test01.py. That is what I see print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters => I think this behaviour can be an IDLE bug. 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. 16 I delete non-ASCII characters. The program is now: print "hola, mundo!" print 17. I save it as test02.py without problems. 18. I close test02.py and open it again. I add non ASCII characters. The program is now: print "¡hola, mundo!" print "áéíóú" 19. I try to save it as test03.py. IDLE shows me the warning message "Non-ASCII found, yet no encoding declared". I click in "Edit my file". The program is now: # -*- coding: cp1252 -*- print "¡hola, mundo!" print "áéíóú" I try to save it again as test03.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test02.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. I am sending attached the test01.py file. By the way, IDLE creates a .idlerc folder (with a recent-files.lst file in it) in the folder where I have created test02.py file. Is it normal? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 09:02 Message: Logged In: YES user_id=80475 I'll continue to work on this one to see if I can use the debugger to isolate the problem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 01:28 Message: Logged In: YES user_id=80475 If Bartolomé is having the same issue I had (on Py2.3b2, but disappeared on PY2.3c1), then the symptoms were: Open Doc/tut/tut.tex Make minor edits Observe: - the stars by the filename show a need for a save - the editor window shows the changes Save (using Cntl-S, File Save, or FileSaveAs) Observe: - no windows pop-up refusing to save - the stars remain - the syntax highlighting indicates that no valid python syntax was found Exit IDLE - get prompted to save and say YES - the exit occurs Look at the file - note that the changes did not take For a brief while, I could re-create this reliably. No one else has been able to reproduce (leading me to think this was specific to WinMe). I could also reproduce it on small files and files like "c:\a.tmp" (leading me to think it was independent of o.s. pathnaming conventions). For a while, I could also reproduce it on a fresh build, but that stopped as soon that the last release candidate changes went in. Sorry for the circuituous report, but if I knew what it was, it would be fixed already. Also, since no one else could reproduce it, I was beginning to suspect my own machine. If Bartolomé is having save problems without getting a warning window then, he is having the same issue. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-21 01:05 Message: Logged In: YES user_id=21627 rhettinger: In IDLE 1.0, IDLE should not ever refuse to safe the file, unless the declared encoding (through the coding: declaration) cannot support the characters in the file. barto: I still don't understand what you did, either in case a) or case b). Can you give precise data? For a), please report what specific encoding you have put into sitecustomize.py, what code page your windows installation uses, and please attach a file that you have created with IDLE 0.8. For b), what do you mean by "save does not work"? Was there some error message? If so, what did it say? If not, what else was wrong. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 00:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 00:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Wed Jul 23 00:07:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 16:07:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-775964 ] fix test_grp failing on RedHat 6.2 Message-ID: Bugs item #775964, was opened at 2003-07-22 19: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=775964&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Barry A. Warsaw (bwarsaw) Summary: fix test_grp failing on RedHat 6.2 Initial Comment: I didn't really think this should go into 2.3, but I'll let you make the decision. This patch fixes the test_grp failure on RedHat 6.2/Alpha (asmodean) in the snake-farm. I thought it was specific to RH 6.2, apparently it's not. If you add a + as the last line in /etc/group the test will fail on RH 9 too. Walter Doerwald may know more about how best to fix this. I'm not certain if it's really a problem in the extension module or the test. If you want to fix the test, the patch is included here: def check_value(self, value): # check that a grp tuple has the entries and # attributes promised by the docs + if value == ('+', None, 0, []): + # some libc's return the last line of + + return ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 From noreply@sourceforge.net Wed Jul 23 01:18:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 17:18:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-775985 ] Solaris error doing a print Message-ID: Bugs item #775985, was opened at 2003-07-23 10:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris error doing a print Initial Comment: As seen on Jeff Hobb's box. print "Registering '%s' (%s)" % (reg_contractid, fname) File "/usr/local/python-2.3/lib/python2.3/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) ValueError: Empty module name It seems that this shell has an empty "LANG" var setup - deleting this var seems to solve the problem. Looking in sysmodule.c, I see: if(codeset && isatty(fileno(stdin))){ (and a similar one for stdout). Should this be: if(codeset && *codeset && isatty(fileno(stdin))){ to prevent an empty name? Or better, should we check the encoding is actually installed? I will mail Jeff and ask him to attach comments on the version or anything else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 From noreply@sourceforge.net Wed Jul 23 01:26:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 17:26:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-775985 ] Solaris error doing a print Message-ID: Bugs item #775985, was opened at 2003-07-22 17:18 Message generated for change (Comment added) made by hobbs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris error doing a print Initial Comment: As seen on Jeff Hobb's box. print "Registering '%s' (%s)" % (reg_contractid, fname) File "/usr/local/python-2.3/lib/python2.3/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) ValueError: Empty module name It seems that this shell has an empty "LANG" var setup - deleting this var seems to solve the problem. Looking in sysmodule.c, I see: if(codeset && isatty(fileno(stdin))){ (and a similar one for stdout). Should this be: if(codeset && *codeset && isatty(fileno(stdin))){ to prevent an empty name? Or better, should we check the encoding is actually installed? I will mail Jeff and ask him to attach comments on the version or anything else. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-22 17:26 Message: Logged In: YES user_id=72656 python 2.3rc1, build --enable-shared. Solaris uname -a: SunOS knife 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra- 250 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 From noreply@sourceforge.net Wed Jul 23 05:39:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 21:39:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-774680 ] Non-ASCII characters bugs Message-ID: Bugs item #774680, was opened at 2003-07-20 22:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bartolomé Sintes Marco (barto) Assigned to: Raymond Hettinger (rhettinger) Summary: Non-ASCII characters bugs Initial Comment: I have downloaded and installed Python 2.3 RC1 in a Spanish Windows 98 SE computer. IDLE 1.0 does not work very well: a) When I open with IDLE 1.0 RC1 a program written with IDLE 0.8, Spanish non-ASCII characters (like voyels with accents) are changed to wrong characters. Some examples: í -> á ó -> ó ú -> ú b) With IDLE 1.0 rc1 I can create a new .py file with non-ASCII characters and save it, but if I reload the same file and I modify it, then I can not save it (neither save it as). If I delete the non-ASCII characters, then I can save (or save it) without problems. If you need more information my adress is BartolomeSintes at ono.com Thanks for your great work! ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-23 06:39 Message: Logged In: YES user_id=21627 IDLE 0.8 interprets this example because of a bug; the data are still bogus. You can use the attached clean.py to convert the file into iso-8859-1. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-23 00:22 Message: Logged In: YES user_id=624347 What does it mean "completely corrupted"? IDLE 0.8 can open and execute it. Is there a way of "cleaning" it? Do you need more information from me? I will be available until Saturday the 26th of July. Best regards. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 23:53 Message: Logged In: YES user_id=21627 I finally understand what is going on. The file test_01.py is completely corrupted. The second line is encoded in Latin-1, whereas the last line is encoded in UTF-8. There is no way IDLE 1.0 could possibly process it in a meaningful way. The problem with saving it still needs to be addressed. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-22 23:40 Message: Logged In: YES user_id=624347 1. I have added getdefaultencoding() to test_01.py: from sys import * print getdefaultencoding() print "¡hola, mundo!" print "áéíóú" In Python 2.2.3 (IDLE 0.8) the ouput of the program is now: cp1252 ¡hola, mundo! áéíóú (as expected) 2. In Python 2.3rc1 (IDLE 1.0rc1) the output of test_01.py is: ascii ¡hola, mundo! áéíóú But I can not save it as test_02.py (as I have explained in my previous post). 3. I delete the non-ASCII characters. test_02.py is now: from sys import * print getdefaultencoding() print "hola, mundo!" print Now I can save it in IDLE 1.0rc1 and the output is: ascii hola, mundo! 4. In IDLE 1.0rc1 I add non-ASCII characters. The program is now: from sys import * print getdefaultencoding() print "¡hola, mundo!" print "áéíóú" But I can not save it as test_03.py (as I have explained in my previous post). 5. I am sending attached test_01.py and test_02.py in a zip file. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 22:45 Message: Logged In: YES user_id=21627 I cannot reproduce the problem, with Windows ME German edition, ActivePython 2.2.1, and Python 2.3b2. In particular, the file opens just fine in step 15, and hence I cannot execute step 16. Step 19 succeeds with saving the file. Can you please attach the three files, preferably as a single ZIP file (see Check to Upload and Attach a File below)? Can you also report what sys.getdefaultencoding() is in your two installations? ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:15 Message: Logged In: YES user_id=624347 Sorry, but there is at least a mistake in my previous message. Item 15 should be: 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py) => I think this behaviour can be an IDLE bug, too. ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 16:10 Message: Logged In: YES user_id=624347 Let's start from the beginning: 1. I uninstall Python from my system (Windows 98 SE Spanish) In my autoexec.bat I can read mode con codepage prepare=((850)C:\WINDOWS\COMMAND\ega.cpi) mode con codepage select=850 keyb sp,,C:\WINDOWS\COMMAND\keyboard.sys 2. I install Python 2.2.3 3. I open IDLE 0.8 4. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 5. If I try to save this file as test01.py, I get the following IDLE message Exception in Tkinter callback Traceback (most recent call last): File "C:\ARCHIVOS DE PROGRAMA\PYTHON223\lib\lib-tk\Tkinter.py", line 1316, in __call__ return apply(self.func, args) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 126, in save self.save_as(event) File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 136, in save_as if self.writefile(filename): File "C:\ARCHIV~1\PYTHON~1\Tools\idle\IOBinding.py", line 151, in writefile chars = str(self.text.get("1.0", "end-1c")) UnicodeError: ASCII encoding error: ordinal not in range(128) 6. I add the following sitecustomize.py file to lib/site-packages: # Set the string encoding used by the Unicode implementation. # The default is 'ascii' encoding = "ascii" # <= CHANGE THIS if you wish # Enable to support locale aware default string encodings. import locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1] print encoding if encoding != "ascii": import sys sys.setdefaultencoding(encoding) 7. I close IDLE 0.8 (without saving test01.py) 8. I open again IDLE 0.8 9. I create the following file: print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters 10. I save the file as test01.py (no messages, no warnings) 11. I close IDLE 0.8 12. I open IDLE 0.8. I load test01.py and run it. Everything is OK. 13. I uninstall Python 2.2.3 and install Python 2.3rc1 14. I open IDLE 1.0rc1 and open test01.py. That is what I see print "¡hola, mundo!" print "áéíóú" # Hello world in Spanish, with non-ASCII characters => I think this behaviour can be an IDLE bug. 15. I try to save test01.py as test02.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test01.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. 16 I delete non-ASCII characters. The program is now: print "hola, mundo!" print 17. I save it as test02.py without problems. 18. I close test02.py and open it again. I add non ASCII characters. The program is now: print "¡hola, mundo!" print "áéíóú" 19. I try to save it as test03.py. IDLE shows me the warning message "Non-ASCII found, yet no encoding declared". I click in "Edit my file". The program is now: # -*- coding: cp1252 -*- print "¡hola, mundo!" print "áéíóú" I try to save it again as test03.py. IDLE shows me the standard save as dialog window. When I click the Save button, nothing happens (the file name is still test02.py and a * is shown before the file name) => I think this behaviour can be an IDLE bug, too. I am sending attached the test01.py file. By the way, IDLE creates a .idlerc folder (with a recent-files.lst file in it) in the folder where I have created test02.py file. Is it normal? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 09:02 Message: Logged In: YES user_id=80475 I'll continue to work on this one to see if I can use the debugger to isolate the problem. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 01:28 Message: Logged In: YES user_id=80475 If Bartolomé is having the same issue I had (on Py2.3b2, but disappeared on PY2.3c1), then the symptoms were: Open Doc/tut/tut.tex Make minor edits Observe: - the stars by the filename show a need for a save - the editor window shows the changes Save (using Cntl-S, File Save, or FileSaveAs) Observe: - no windows pop-up refusing to save - the stars remain - the syntax highlighting indicates that no valid python syntax was found Exit IDLE - get prompted to save and say YES - the exit occurs Look at the file - note that the changes did not take For a brief while, I could re-create this reliably. No one else has been able to reproduce (leading me to think this was specific to WinMe). I could also reproduce it on small files and files like "c:\a.tmp" (leading me to think it was independent of o.s. pathnaming conventions). For a while, I could also reproduce it on a fresh build, but that stopped as soon that the last release candidate changes went in. Sorry for the circuituous report, but if I knew what it was, it would be fixed already. Also, since no one else could reproduce it, I was beginning to suspect my own machine. If Bartolomé is having save problems without getting a warning window then, he is having the same issue. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-21 01:05 Message: Logged In: YES user_id=21627 rhettinger: In IDLE 1.0, IDLE should not ever refuse to safe the file, unless the declared encoding (through the coding: declaration) cannot support the characters in the file. barto: I still don't understand what you did, either in case a) or case b). Can you give precise data? For a), please report what specific encoding you have put into sitecustomize.py, what code page your windows installation uses, and please attach a file that you have created with IDLE 0.8. For b), what do you mean by "save does not work"? Was there some error message? If so, what did it say? If not, what else was wrong. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-21 00:51 Message: Logged In: YES user_id=80475 Part b) very closely resembles the problem I was having (and can no longer reproduce) in editting Doc/tut/tut.tex. Something in the save procedure silently aborts the save if there is something it doesn't like in the file (encoding issues, sizes, name issues, python syntax highlighting issues, or somesuch). ---------------------------------------------------------------------- Comment By: Bartolomé Sintes Marco (barto) Date: 2003-07-21 00:47 Message: Logged In: YES user_id=624347 bug a) When I began to use IDLE 0.8, I could not use non-ASCII characters. As I read in http://www.python.org/cgi- bin/faqw.py? query=4.102&querytype=simple&casefold=yes&req=search I created a sitecustomize.py file in lib/site-packages and then I have been able to use non-ASCII characters (in IDLE 0.8) in my programs. Now when I open these programs with IDLE 1.0rc1, it shows wrong non-ASCII characters (and yes, Notepad shows the same wrong characters). I thought it was a IDLE 1.0rc1 bug, but surely you are right and it is an 0.8 IDLE bug. The question is if there is an easy way to solve this problem (apart find and replace) and if it should be stated somewhere. bug b) You are right. IDLE 1.0rc1 shows a warning if the file is created with IDLE 1.0rc1. I made a mistake in my report. What I have done is opening with IDLE 1.0rc1 a file created with IDLE 0.8, deleting the non-ASCII characters and saving it. But if I add later some non-ASCII characters to this file with IDLE 1.0rc1, then save does not work (even if I manually add the # -*- coding: cp1252 -*- line) and it does not show any warning. I think I have not changed the default configuration of IDLE 1.0rc1 (Options/General/Default source encoding is set to none). I have not added the old sitecustomize.py to the Python 2.3rc1 installation . ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-20 23:10 Message: Logged In: YES user_id=21627 Why do you think this is a bug in IDLE 1.0, when it is IDLE 0.8 which displays the data incorrectly? Can you report what notepad.exe thinks about these files? Or better, can you please attach one such file here? Can you try adding a line # -*- coding: iso-8859-1 -*- as the first line of your file before saving it in IDLE, and see whether this changes anything? Did IDLE ever propose to add such a line? Did you somehow change the default configuration of IDLE, through Options/Configure IDLE/General? Did you edit site.py, or sitecustomize.py to change the default encoding`? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774680&group_id=5470 From noreply@sourceforge.net Wed Jul 23 06:04:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 22:04:40 -0700 Subject: [Python-bugs-list] [ python-Bugs-775541 ] idle.py doesn't accept ( in some cases Message-ID: Bugs item #775541, was opened at 2003-07-22 04:31 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775541&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open >Resolution: Accepted >Priority: 8 Submitted By: Gregor Lingl (glingl) >Assigned to: Kurt B. Kaiser (kbk) Summary: idle.py doesn't accept ( in some cases Initial Comment: I start IDLE in one-process-mode, in order to be able to use turtle.py in interactive mode. i:\python23\python.exe idle.py -n I enter in the shell-window: Python 2.3c1 (#44, Jul 18 2003, 14:32:36) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0rc1 ==== No Subprocess ==== >>> from turtle import * >>> Exception in Tkinter callback Traceback (most recent call last): File "I:\Python23\lib\lib-tk\Tkinter.py", line 1345, in __call__ return self.func(*args) File "i:\python23\lib\idlelib\CallTips.py", line 47, in paren_open_event arg_text = self.fetch_tip(name) File "i:\python23\lib\idlelib\CallTips.py", line 106, in fetch_tip return get_arg_text(entity) File "i:\python23\lib\idlelib\CallTips.py", line 165, in get_arg_text doc = getattr(ob, "__doc__", "").lstrip() AttributeError: 'NoneType' object has no attribute 'lstrip' forward( Just after typing the opening parentheses after the function name forward the shown error-message appears, and the just typed in forward( is appended to it. When I continue e.g. with 50), the turtle does, what I want. The same with all following function-calls. Maybe the reason for this bug lies (in some way) in turtle.py. Nevertheless, IMHO IDLE SHOULD accept modules like turtle.py withoult breaking (I can't understand how getattr with 3. arg "" can return NoneType at all. Or is this a bug in getattr?) Interestingly IDLE started ordinarily in multiprocess mode doesn't show this behaviour. >>> from turtle import * >>> forward(50 Alas! It's not recommended to complete this, as then IDLE would hang from other reasons ... Regards, Gregor ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 00:04 Message: Logged In: YES user_id=149084 functions/methods with no docstrings will raise this error. Patch 776062 submitted for 2.3rc2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775541&group_id=5470 From noreply@sourceforge.net Wed Jul 23 06:16:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 22:16:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-775985 ] Solaris error doing a print Message-ID: Bugs item #775985, was opened at 2003-07-23 02:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris error doing a print Initial Comment: As seen on Jeff Hobb's box. print "Registering '%s' (%s)" % (reg_contractid, fname) File "/usr/local/python-2.3/lib/python2.3/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) ValueError: Empty module name It seems that this shell has an empty "LANG" var setup - deleting this var seems to solve the problem. Looking in sysmodule.c, I see: if(codeset && isatty(fileno(stdin))){ (and a similar one for stdout). Should this be: if(codeset && *codeset && isatty(fileno(stdin))){ to prevent an empty name? Or better, should we check the encoding is actually installed? I will mail Jeff and ask him to attach comments on the version or anything else. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-23 07:16 Message: Logged In: YES user_id=21627 I'm tempted to declare this a platform bug: Both Linux and later Solaris versions set the CODEPAGE to ASCII for an empty LANG (i.e. assume this is the "C" locale). Still, checking whether the encoding is present is probably a good idea. Unfortunately, it cannot be done right there, since loading of codecs does not work yet inside _PySys_Init. So as a work-around for 2.3, we should check for non-empty strings, and leave checking for supported encodings for 2.3.1. Patch attached. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-23 02:26 Message: Logged In: YES user_id=72656 python 2.3rc1, build --enable-shared. Solaris uname -a: SunOS knife 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra- 250 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 From noreply@sourceforge.net Wed Jul 23 06:20:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 22:20:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-775535 ] Tooltip-window doesn't vanish if... Message-ID: Bugs item #775535, was opened at 2003-07-22 04:14 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775535&group_id=5470 Category: IDLE >Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Gregor Lingl (glingl) >Assigned to: Kurt B. Kaiser (kbk) Summary: Tooltip-window doesn't vanish if... Initial Comment: When entering in the shell window of IDLE: >>> len( a tooltip-window appears with content len(object) -> integer Now, when deleting these four characters (or at least the opening parentheses) the tooltip-window remains open. I can enter other expressions, writing even behind this tooltip-window and it vanishes only - when clicking the shell-window with the mouse - when minimizing and remaximizing the shell-window - wehn using another function call and typing a new opening parentheses. It should vanish immediately, when the opening parentheses is deleted. Regards, Gregor ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 00:20 Message: Logged In: YES user_id=149084 Related to IDLEfork Bug 683123: ESC doesn't close the call tip. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775535&group_id=5470 From noreply@sourceforge.net Wed Jul 23 06:23:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 22 Jul 2003 22:23:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-775353 ] IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work Message-ID: Bugs item #775353, was opened at 2003-07-21 18:54 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775353&group_id=5470 Category: IDLE >Group: Python 2.4 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Matthew Shomphe (mshomphe) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work Initial Comment: Info: -Python Version: Python 2.3c1 (#44, Jul 18 2003, 14:32: 36) [MSC v.1200 32 bit (Intel)] on win32 -IDLE Version:IDLE 1.0rc1 -OS: Windows 2000 SP4 -Source: Installed from Installer on website (http://www. python.org/ftp/python/2.3/Python-2.3c1.exe) Behavior: In the "File" dropdown menu in IDLE, the listed keybind for "Save As" is Ctrl+Shift+S. This does not work. When you hit Ctrl+Shift+S, nothing happens. Additionally, the keybind for "Save Copy As...", Alt+Shift+S, does not work. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 00:23 Message: Logged In: YES user_id=149084 Duplicate of IDLEfork Bug 755647 None of the bindings with a Shift modifier work because it is then necessary to use the upper case keysym. IDLE is using the lower case. ---------------------------------------------------------------------- Comment By: Matthew Shomphe (mshomphe) Date: 2003-07-21 19:32 Message: Logged In: YES user_id=716326 Checking through the code, it seems that the problem is in the file "configHandler.py". The bindings are assigned with _lowercase_ letters: '<>': [''], '<>': [''], So the keybindings will work when CAPSLOCK is active. Otherwise, it won't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775353&group_id=5470 From noreply@sourceforge.net Wed Jul 23 10:04:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 02:04:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-775892 ] test_coercion failing on Panther Message-ID: Bugs item #775892, was opened at 2003-07-22 23:16 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775892&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_coercion failing on Panther Initial Comment: Test_coercion is failing on Panther. All the failures have the same form: the output is (XXX-0j) in stead of the expected (XXX+0j). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-23 11:04 Message: Logged In: YES user_id=45365 Edward had also come across the bug, and suggests the following: The workaround is to add the complier flag "-mno-fused-madd". This works for Jaguar and Panther, but I don't know how far back it may go. My test report for c1 uses this flag. The question is: do we fix this for rc2 or leave it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-22 23:29 Message: Logged In: YES user_id=31435 Ignore it -- the sign of a float 0 is more accidental than not. If the compiler has a switch to disable generation of fused multiply-add instructions, the failure will probably go away. After 2.3, we should rewrite the test so that "sign of 0" cases aren't even tried anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775892&group_id=5470 From noreply@sourceforge.net Wed Jul 23 11:49:46 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 03:49:46 -0700 Subject: [Python-bugs-list] [ python-Bugs-776116 ] pythonw scripts cannot interact Message-ID: Bugs item #776116, was opened at 2003-07-23 10:34 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776116&group_id=5470 >Category: None Group: None Status: Open >Resolution: Fixed Priority: 9 Submitted By: Jack Jansen (jackjansen) >Assigned to: Nobody/Anonymous (nobody) Summary: pythonw scripts cannot interact Initial Comment: In MacPython 2.3rc1+ a bug has crept into pythonw which has the result that scripts run with it cannot interact with the user. The windows show up, but there is no menubar, no interaction and no dock icon. This hasn't been tested yet with CVS python, so it could be an error in the build process of the binary distribution. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-23 12:49 Message: Logged In: YES user_id=45365 Fixed in Mac/OSX/Makefile rev. 1.50, Mac/OSX/Dist/resources/ postflight rev 1.7. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-23 10:46 Message: Logged In: YES user_id=45365 Turns out it is a shallow bug: the binary inside Python.app was renamed from "python" to "Python" to adhere to Apple's guidelines (as pointed out by our Apple guy). But the pythonw script still referred to it as "python", which sort-of works because of the case insensitive filesystem, but because Python != python the window manager doesn't allow access. Fixing and testing will take a little while longer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776116&group_id=5470 From noreply@sourceforge.net Wed Jul 23 11:55:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 03:55:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-764975 ] Installing 2.3b2 on to non-system disk fails Message-ID: Bugs item #764975, was opened at 2003-07-03 00:45 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764975&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None >Priority: 3 Submitted By: Rob Managan (managan) Assigned to: Jack Jansen (jackjansen) Summary: Installing 2.3b2 on to non-system disk fails Initial Comment: When installing 2.3b2 I was allowed to choose a non-system disk. It did create an Applications folder and installed into it. Parts of the framework were installed correctly (based onmod dates) but it did not work properly. After installing on the system disk the IDE worked fine but the package manager did not except from within the IDE. I suspect double clicking on the Package Manager was trying to use an older version of python, possibly Apple's. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-23 12:55 Message: Logged In: YES user_id=45365 For some reason setting rootDiskOnly causes strange error messages to appear in the installer, and you have to switch disks back and forth to make installation possible. And people with only one disk don't even have this option. The problem is probably that the packages created by our buildpkg.py module aren't fully adhering to the (unwritten) standard. For now the workaround is to allow non-system-disk installs, but warn people in the welcome message that this doesn't work. For the future we should either fix buildpkg or replace it with a module that uses OSA to talk to the Apple Package Maker tool. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764975&group_id=5470 From noreply@sourceforge.net Wed Jul 23 11:56:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 03:56:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-776116 ] pythonw scripts cannot interact Message-ID: Bugs item #776116, was opened at 2003-07-23 10:34 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776116&group_id=5470 Category: None Group: None >Status: Closed Resolution: Fixed Priority: 9 Submitted By: Jack Jansen (jackjansen) >Assigned to: Jack Jansen (jackjansen) Summary: pythonw scripts cannot interact Initial Comment: In MacPython 2.3rc1+ a bug has crept into pythonw which has the result that scripts run with it cannot interact with the user. The windows show up, but there is no menubar, no interaction and no dock icon. This hasn't been tested yet with CVS python, so it could be an error in the build process of the binary distribution. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-23 12:49 Message: Logged In: YES user_id=45365 Fixed in Mac/OSX/Makefile rev. 1.50, Mac/OSX/Dist/resources/ postflight rev 1.7. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-23 10:46 Message: Logged In: YES user_id=45365 Turns out it is a shallow bug: the binary inside Python.app was renamed from "python" to "Python" to adhere to Apple's guidelines (as pointed out by our Apple guy). But the pythonw script still referred to it as "python", which sort-of works because of the case insensitive filesystem, but because Python != python the window manager doesn't allow access. Fixing and testing will take a little while longer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776116&group_id=5470 From noreply@sourceforge.net Wed Jul 23 12:02:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 04:02:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-776181 ] Small type in reference for __ixor__ Message-ID: Bugs item #776181, was opened at 2003-07-23 13:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776181&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Francesco Ricciardi (nerby) Assigned to: Nobody/Anonymous (nobody) Summary: Small type in reference for __ixor__ Initial Comment: In chapter 3.3.6 'Emulating numeric types' of the HTML version of the Reference Manual, in the description of the augmented arithmetic operators, the second to last symbol is '=' instead of '^='. This is true for various Python versions, but only for the HTML code (PDF and Postscript do have '^='). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776181&group_id=5470 From noreply@sourceforge.net Wed Jul 23 13:02:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 05:02:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-776202 ] MacOS9: test_uu fails Message-ID: Bugs item #776202, was opened at 2003-07-23 14:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: test_uu fails Initial Comment: test_uu fails on MacPython-OS9: AssertionError: 'The smooth-scaled python crept over the sleeping dog\r' != 'The smooth-scaled python crept over the sleeping dog\n' Presumably it mixes binary and text I/O. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 From noreply@sourceforge.net Wed Jul 23 13:04:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 05:04:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-776203 ] MacOS9: test_urllib fails Message-ID: Bugs item #776203, was opened at 2003-07-23 14: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=776203&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: test_urllib fails Initial Comment: test_urllib fails in MacPython-OS9: File "Sap:ufs:jack:SWDev:MacPython:Lib:test:test_urllib.py", line 109, in test_basic self.assertEqual(result[0], test_support.TESTFN) File "Sap:ufs:jack:SWDev:MacPython:Lib:unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: ':@test' != '@test' probably a call to os.path.normpath() on both sides of the equality test will do the job. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776203&group_id=5470 From noreply@sourceforge.net Wed Jul 23 13:05:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 05:05:59 -0700 Subject: [Python-bugs-list] [ python-Bugs-776205 ] MacOS9: test_strptime fails Message-ID: Bugs item #776205, was opened at 2003-07-23 14: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=776205&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: test_strptime fails Initial Comment: Test_strptime fails in MacPython-OS9: test test_strptime failed -- Traceback (most recent call last): File "Sap:ufs:jack:SWDev:MacPython:Lib:test:test_strptime.py", line 308, in test_timezone "timezone check failed; '%s' -> %s != %s" % File "Sap:ufs:jack:SWDev:MacPython:Lib:unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: timezone check failed; '' -> 0 != 1 Probably this specific test should be skipped on the mac, which has no useful timezone information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776205&group_id=5470 From noreply@sourceforge.net Wed Jul 23 13:08:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 05:08:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-776207 ] MacOS9: test_posixpath fails Message-ID: Bugs item #776207, was opened at 2003-07-23 14: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=776207&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: test_posixpath fails Initial Comment: test_posixpath fails on MacPython-OS9: test test_posixpath failed -- Traceback (most recent call last): File "Sap:ufs:jack:SWDev:MacPython:Lib:test:test_posixpath.py" , line 329, in test_ismount self.assertIs(posixpath.ismount("/"), True) File "Sap:ufs:jack:SWDev:MacPython:Lib:test:test_posixpath.py" , line 9, in assertIs self.assert_(a is b) File "Sap:ufs:jack:SWDev:MacPython:Lib:unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError I am unsure about the fix, because I don't know what the intention of posixpath.ismount() is on a non-posix system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776207&group_id=5470 From noreply@sourceforge.net Wed Jul 23 13:09:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 05:09:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-776209 ] MacOS9: test_csv fails Message-ID: Bugs item #776209, was opened at 2003-07-23 14: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=776209&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: test_csv fails Initial Comment: test_cvs fails on MacPython-OS9: test_csv test test_csv crashed -- exceptions.AttributeError: 'module' object has no attribute 'excel' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776209&group_id=5470 From noreply@sourceforge.net Wed Jul 23 13:59:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 05:59:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 20:21 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-23 12:59 Message: Logged In: YES user_id=52562 Could you tell me how to find out why distutils doesn't use the -R/-rpath option? Could it be that it assumes /usr/local/lib is already going to be in the ld path? By the way, having manually added /usr/local/lib to my /etc/ld.so.conf, it compiles with no errors, but make test yields the following: HACK pion:~/playground/python/python/dist/src$ grep -i -E --regex="bsddb|berk|db[^A-Za-z]" /tmp/zooko/logs/make.test.python test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd Is that right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 21:05 Message: Logged In: YES user_id=21627 Ok. Can you try to find out why distutils fails to use the -R/-rpath option? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 21:02 Message: Logged In: YES user_id=52562 Okay, I've tried these. -Wl,verbose tells me, as I expected: attempt to open /usr/local/stow/python-g/lib/libdb-4.1.so failed attempt to open /usr/local/stow/python-g/lib/libdb-4.1.a failed attempt to open /usr/local/lib/libdb-4.1.so succeeded -ldb-4.1 (/usr/local/lib/libdb-4.1.so) nm tells me, as expected, that db_create is present: MAIL pion:~$ nm /usr/local/lib/libdb-4.1.so | grep db_create 0001a554 T __bam_db_create 000783cc T __ham_db_create 000a5fe0 T __qam_db_create 000492c8 T db_create Adding /usr/local/lib to my /etc/ld.so.conf and running ldconfig *did* fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 20:41 Message: Logged In: YES user_id=21627 Please collect the following information: 1. Invoke the linker line with -Wl,--verbose (manually), to find out the path it uses for the -ldb-4.1 command line option. In particular, find out whether it uses a shared or static library (.so or .a) 2. Perform nm on that library|grep db_create The symbol really should be there; it is on all copies of -ldb-something that I can get hold of. If it is not in your copy, you somehow messed up the BerkeleyDB build. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 20:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 20:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Wed Jul 23 14:07:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 06:07:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-776181 ] Small type in reference for __ixor__ Message-ID: Bugs item #776181, was opened at 2003-07-23 06:02 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776181&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Francesco Ricciardi (nerby) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Small type in reference for __ixor__ Initial Comment: In chapter 3.3.6 'Emulating numeric types' of the HTML version of the Reference Manual, in the description of the augmented arithmetic operators, the second to last symbol is '=' instead of '^='. This is true for various Python versions, but only for the HTML code (PDF and Postscript do have '^='). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776181&group_id=5470 From noreply@sourceforge.net Wed Jul 23 16:16:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 08:16:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-776311 ] Regular expression failure of the sre engine Message-ID: Bugs item #776311, was opened at 2003-07-23 17: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=776311&group_id=5470 Category: Regular Expressions Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Wolfgang Grafen (grafen) Assigned to: Fredrik Lundh (effbot) Summary: Regular expression failure of the sre engine Initial Comment: Don't depreciate pre as we all will loose a useful verification tool for sre! >From time to time I have situations where I wonder why re(sre) doesn't match its input. Then I change to pre (import pre as re) and several times it happened that pre worked fine while sre did not. Sorry that I didn't track down the error but if you are interested in the testcase I attached the test case for you. (This failure is in a regular expression which maches a complete pattern of a VHDL Architecture to apply a patch on it so it was quick hack but a large regex. The other failures I cannot remember what it was, sorry) Regards Wolfgang Grafen --------------------------------------- I will be absent until 5 September 2003 --------------------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776311&group_id=5470 From noreply@sourceforge.net Wed Jul 23 16:19:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 08:19:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-776181 ] Small typo in reference for __ixor__ Message-ID: Bugs item #776181, was opened at 2003-07-23 07:02 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776181&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open >Resolution: Fixed Priority: 5 Submitted By: Francesco Ricciardi (nerby) Assigned to: Fred L. Drake, Jr. (fdrake) >Summary: Small typo in reference for __ixor__ Initial Comment: In chapter 3.3.6 'Emulating numeric types' of the HTML version of the Reference Manual, in the description of the augmented arithmetic operators, the second to last symbol is '=' instead of '^='. This is true for various Python versions, but only for the HTML code (PDF and Postscript do have '^='). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-23 11:19 Message: Logged In: YES user_id=3066 Fixed for Python 2.3 in Doc/ref/ref3.tex revision 1.114. Should be backported; leaving this report open until that's done, but marking as Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776181&group_id=5470 From noreply@sourceforge.net Wed Jul 23 22:20:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 14:20:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-776533 ] Carbon.Snd module SPB constructor shadowed Message-ID: Bugs item #776533, was opened at 2003-07-23 16: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=776533&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marcus Mendenhall (mendenhall) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.Snd module SPB constructor shadowed Initial Comment: I recently found an apparent bug in the automatically generated wrappers for Carbon.Snd. There is a name conflict over SPB, which is both declared as a type object, and as a constructor for an SPB. The type object is shadowing the SPB constructor, so it is impossible to build SPBs, and thus impossible to do much with the module. There are two names for the SPB data type -- SPB and SPBType, generated by the wrapper generator. The SPBType should probably be kept, while SPB() should be unshadowed to allow creation of SPBs. The error can be trivially replicated by just importing Carbon.Snd and attempting to create an SPB with a=Snd.SPB(), which returns an error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776533&group_id=5470 From noreply@sourceforge.net Wed Jul 23 22:40:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 14:40:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-776542 ] urllib: open_https generates wrong Authorize header Message-ID: Bugs item #776542, was opened at 2003-07-23 17: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=776542&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Steffen Ries (sries) Assigned to: Nobody/Anonymous (nobody) Summary: urllib: open_https generates wrong Authorize header Initial Comment: When opening an https page which requires authentication, the "Authorization" header is created incorrectly by open_https(). open_http() uses the correct method. The fix is a simple one line change: *** /usr/local/lib/python2.2/urllib.py Fri Oct 4 18:57:01 2002 --- urllib.py Wed Jul 23 17:23:41 2003 *************** *** 364,370 **** h.putheader('Content-length', '%d' % len(data)) else: h.putrequest('GET', selector) ! if auth: h.putheader('Authorization: Basic %s' % auth) if realhost: h.putheader('Host', realhost) for args in self.addheaders: apply(h.putheader, args) h.endheaders() --- 364,370 ---- h.putheader('Content-length', '%d' % len(data)) else: h.putrequest('GET', selector) ! if auth: h.putheader('Authorization', 'Basic %s' % auth) if realhost: h.putheader('Host', realhost) for args in self.addheaders: apply(h.putheader, args) h.endheaders() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776542&group_id=5470 From noreply@sourceforge.net Wed Jul 23 22:43:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 14:43:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-775541 ] idle.py doesn't accept ( in some cases Message-ID: Bugs item #775541, was opened at 2003-07-22 05:31 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775541&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: Accepted Priority: 8 Submitted By: Gregor Lingl (glingl) Assigned to: Kurt B. Kaiser (kbk) Summary: idle.py doesn't accept ( in some cases Initial Comment: I start IDLE in one-process-mode, in order to be able to use turtle.py in interactive mode. i:\python23\python.exe idle.py -n I enter in the shell-window: Python 2.3c1 (#44, Jul 18 2003, 14:32:36) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0rc1 ==== No Subprocess ==== >>> from turtle import * >>> Exception in Tkinter callback Traceback (most recent call last): File "I:\Python23\lib\lib-tk\Tkinter.py", line 1345, in __call__ return self.func(*args) File "i:\python23\lib\idlelib\CallTips.py", line 47, in paren_open_event arg_text = self.fetch_tip(name) File "i:\python23\lib\idlelib\CallTips.py", line 106, in fetch_tip return get_arg_text(entity) File "i:\python23\lib\idlelib\CallTips.py", line 165, in get_arg_text doc = getattr(ob, "__doc__", "").lstrip() AttributeError: 'NoneType' object has no attribute 'lstrip' forward( Just after typing the opening parentheses after the function name forward the shown error-message appears, and the just typed in forward( is appended to it. When I continue e.g. with 50), the turtle does, what I want. The same with all following function-calls. Maybe the reason for this bug lies (in some way) in turtle.py. Nevertheless, IMHO IDLE SHOULD accept modules like turtle.py withoult breaking (I can't understand how getattr with 3. arg "" can return NoneType at all. Or is this a bug in getattr?) Interestingly IDLE started ordinarily in multiprocess mode doesn't show this behaviour. >>> from turtle import * >>> forward(50 Alas! It's not recommended to complete this, as then IDLE would hang from other reasons ... Regards, Gregor ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-23 17:43 Message: Logged In: YES user_id=12800 Kurt, you applied the referenced patch, right? So this bug report can be closed, right? If so, please do. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 01:04 Message: Logged In: YES user_id=149084 functions/methods with no docstrings will raise this error. Patch 776062 submitted for 2.3rc2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775541&group_id=5470 From noreply@sourceforge.net Wed Jul 23 23:03:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 15:03:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-775541 ] idle.py doesn't accept ( in some cases Message-ID: Bugs item #775541, was opened at 2003-07-22 04:31 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775541&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: Accepted >Priority: 2 Submitted By: Gregor Lingl (glingl) Assigned to: Kurt B. Kaiser (kbk) Summary: idle.py doesn't accept ( in some cases Initial Comment: I start IDLE in one-process-mode, in order to be able to use turtle.py in interactive mode. i:\python23\python.exe idle.py -n I enter in the shell-window: Python 2.3c1 (#44, Jul 18 2003, 14:32:36) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0rc1 ==== No Subprocess ==== >>> from turtle import * >>> Exception in Tkinter callback Traceback (most recent call last): File "I:\Python23\lib\lib-tk\Tkinter.py", line 1345, in __call__ return self.func(*args) File "i:\python23\lib\idlelib\CallTips.py", line 47, in paren_open_event arg_text = self.fetch_tip(name) File "i:\python23\lib\idlelib\CallTips.py", line 106, in fetch_tip return get_arg_text(entity) File "i:\python23\lib\idlelib\CallTips.py", line 165, in get_arg_text doc = getattr(ob, "__doc__", "").lstrip() AttributeError: 'NoneType' object has no attribute 'lstrip' forward( Just after typing the opening parentheses after the function name forward the shown error-message appears, and the just typed in forward( is appended to it. When I continue e.g. with 50), the turtle does, what I want. The same with all following function-calls. Maybe the reason for this bug lies (in some way) in turtle.py. Nevertheless, IMHO IDLE SHOULD accept modules like turtle.py withoult breaking (I can't understand how getattr with 3. arg "" can return NoneType at all. Or is this a bug in getattr?) Interestingly IDLE started ordinarily in multiprocess mode doesn't show this behaviour. >>> from turtle import * >>> forward(50 Alas! It's not recommended to complete this, as then IDLE would hang from other reasons ... Regards, Gregor ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 17:03 Message: Logged In: YES user_id=149084 Basic cause is fixed. I had some comments on his comments on turtle.py which I'm holding off until I can get 2.3rc2 on XP. Lowering priority. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-23 16:43 Message: Logged In: YES user_id=12800 Kurt, you applied the referenced patch, right? So this bug report can be closed, right? If so, please do. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 00:04 Message: Logged In: YES user_id=149084 functions/methods with no docstrings will raise this error. Patch 776062 submitted for 2.3rc2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775541&group_id=5470 From noreply@sourceforge.net Wed Jul 23 23:19:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 15:19:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-775892 ] test_coercion failing on Panther Message-ID: Bugs item #775892, was opened at 2003-07-22 23:16 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775892&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: test_coercion failing on Panther Initial Comment: Test_coercion is failing on Panther. All the failures have the same form: the output is (XXX-0j) in stead of the expected (XXX+0j). ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-24 00:19 Message: Logged In: YES user_id=45365 Fixed in configure.in rev. 1.427, configure rev. 1.416. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-23 11:04 Message: Logged In: YES user_id=45365 Edward had also come across the bug, and suggests the following: The workaround is to add the complier flag "-mno-fused-madd". This works for Jaguar and Panther, but I don't know how far back it may go. My test report for c1 uses this flag. The question is: do we fix this for rc2 or leave it? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-22 23:29 Message: Logged In: YES user_id=31435 Ignore it -- the sign of a float 0 is more accidental than not. If the compiler has a switch to disable generation of fused multiply-add instructions, the failure will probably go away. After 2.3, we should rewrite the test so that "sign of 0" cases aren't even tried anymore. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775892&group_id=5470 From noreply@sourceforge.net Wed Jul 23 23:28:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 15:28:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-775541 ] idle.py doesn't accept ( in some cases Message-ID: Bugs item #775541, was opened at 2003-07-22 04:31 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775541&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: Accepted Priority: 2 Submitted By: Gregor Lingl (glingl) Assigned to: Kurt B. Kaiser (kbk) Summary: idle.py doesn't accept ( in some cases Initial Comment: I start IDLE in one-process-mode, in order to be able to use turtle.py in interactive mode. i:\python23\python.exe idle.py -n I enter in the shell-window: Python 2.3c1 (#44, Jul 18 2003, 14:32:36) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information. IDLE 1.0rc1 ==== No Subprocess ==== >>> from turtle import * >>> Exception in Tkinter callback Traceback (most recent call last): File "I:\Python23\lib\lib-tk\Tkinter.py", line 1345, in __call__ return self.func(*args) File "i:\python23\lib\idlelib\CallTips.py", line 47, in paren_open_event arg_text = self.fetch_tip(name) File "i:\python23\lib\idlelib\CallTips.py", line 106, in fetch_tip return get_arg_text(entity) File "i:\python23\lib\idlelib\CallTips.py", line 165, in get_arg_text doc = getattr(ob, "__doc__", "").lstrip() AttributeError: 'NoneType' object has no attribute 'lstrip' forward( Just after typing the opening parentheses after the function name forward the shown error-message appears, and the just typed in forward( is appended to it. When I continue e.g. with 50), the turtle does, what I want. The same with all following function-calls. Maybe the reason for this bug lies (in some way) in turtle.py. Nevertheless, IMHO IDLE SHOULD accept modules like turtle.py withoult breaking (I can't understand how getattr with 3. arg "" can return NoneType at all. Or is this a bug in getattr?) Interestingly IDLE started ordinarily in multiprocess mode doesn't show this behaviour. >>> from turtle import * >>> forward(50 Alas! It's not recommended to complete this, as then IDLE would hang from other reasons ... Regards, Gregor ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 17:28 Message: Logged In: YES user_id=149084 Basic cause is fixed. I had some comments on his comments on turtle.py which I'm holding off until I can get 2.3rc2 on XP. Lowering priority. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 17:03 Message: Logged In: YES user_id=149084 Basic cause is fixed. I had some comments on his comments on turtle.py which I'm holding off until I can get 2.3rc2 on XP. Lowering priority. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-23 16:43 Message: Logged In: YES user_id=12800 Kurt, you applied the referenced patch, right? So this bug report can be closed, right? If so, please do. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-23 00:04 Message: Logged In: YES user_id=149084 functions/methods with no docstrings will raise this error. Patch 776062 submitted for 2.3rc2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775541&group_id=5470 From noreply@sourceforge.net Thu Jul 24 00:36:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 16:36:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-773286 ] nconsistant results for os.listdir,os.path.isdir on W2k Message-ID: Bugs item #773286, was opened at 2003-07-17 14:36 Message generated for change (Comment added) made by remerson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773286&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Richard F. Emerson (remerson) Assigned to: Nobody/Anonymous (nobody) Summary: nconsistant results for os.listdir,os.path.isdir on W2k Initial Comment: Inconsistant results when using os.listdir,os.path.isdir and os.path.isfile on the win200 platform. Run the following script and compare with a directroy view. They do not match for the second directory of the two. """ to separate the sub directories from the files in a directory""" import os p1=os.getcwd() x=os.listdir(p1) p2= os.path.join("c:\","python~1","Tools") y=os.listdir(p2) #cwd = os.path.join("c:\") #cwd=cwd+"\doc\" #cwd="c:\python~1\Doc" #cwd=cwd+"\Qualcomm"+"\Eduora" #print x,y print "path",p1,"\n" print "directories","\n" for item in x: #print item if os.path.isdir(item): print " ",item print "\n","files","\n" for item in os.listdir(cwd): if os.path.isfile(item): print " ",item print "path",p2,"\n" print "directories","\n" for item in y: #print item if os.path.isdir(item): print " ",item print "\n","files","\n" for item in os.listdir(cwd): if os.path.isfile(item): print " ",item the lists x and y do contain all the file and directory names and one would expect the same sorting of both lists into directories only and files only. Not so on my machine. Results path C:\PYTHON~1 directories DLLs Doc include Lib libs Qualcomm tcl Tools files Circle.py Circle.pyc INSTALL.LOG LICENSE.txt log.bak Log.py Log.pyc mailspin.py mailspin.pyc mailspin1.py NEWS.txt py.ico pyc.ico pycon.ico python.exe pythonw.exe README.txt Requirements for the Message Separator.doc session.txt test dirs.py test dirs1.py test file.txt w9xpopen.exe path c:\python~1\Tools directories files Circle.py Circle.pyc INSTALL.LOG LICENSE.txt log.bak Log.py Log.pyc mailspin.py mailspin.pyc mailspin1.py NEWS.txt py.ico pyc.ico pycon.ico python.exe pythonw.exe README.txt Requirements for the Message Separator.doc session.txt test dirs.py test dirs1.py test file.txt w9xpopen.exe The tools sub directory is as delivered with the distribution. The Python~1 directory has had a few files added. Though I am new to Python, I tried locating the functions or classes that implemented the dirlist, isdir and isfile with only limited success. I looked in os, os.path and ntpath. I can be reached by phone at 818.354.3848 if more immediate communications is required to understand the problem (mine or the library's ) and resolve it. Regards Dick ---------------------------------------------------------------------- >Comment By: Richard F. Emerson (remerson) Date: 2003-07-23 16:36 Message: Logged In: YES user_id=824995 Recommend closing this bug as the vagueness lies in the documentation. Alternatively, return an error if the path provided is not an abspath. Either way the documentation should be updated. The library routines os.path.isdir() and os.path.isfile() require that the path argument be an abspath. In the absence of an abspath they use the cwd as the pbase path and prepend it to the data found with the os.listdir() request. Hence it works for the first case I tried bu not the second, yet it doesnt complain. Thanks for your rapid response. Checking into the questions asked led to the solution. Regards Dick ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-17 19:11 Message: Logged In: YES user_id=80475 What is the issue? * Is it a matter of os.listdir() having a sort order different from that shown by another windows tool? If so, then that is not a bug (the sort order is not guaranteed by the underlying o.s.). * Is there another tool that makes different idenfications of what is a directory vs what is a file? If so, please include a DOS listing of the file attributes ("attrib *.*") and a similar list from Python: for filename is os.listdir(p): print filename, os.isdir(filename), os.isfile(filename) * Is there any internal inconsistency within Python. If so, please show the comparative result. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773286&group_id=5470 From noreply@sourceforge.net Thu Jul 24 00:54:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 16:54:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-776600 ] PIL binary package missing jpeg support (pimp) Message-ID: Bugs item #776600, was opened at 2003-07-23 19:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776600&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PIL binary package missing jpeg support (pimp) Initial Comment: Binary installation of PIL should be compiled with a static libjpeg. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776600&group_id=5470 From noreply@sourceforge.net Thu Jul 24 00:58:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 16:58:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-776602 ] readline should be in PackageManager database Message-ID: Bugs item #776602, was opened at 2003-07-23 19:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776602&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: readline should be in PackageManager database Initial Comment: http://undefined.org/~bob/readline-0.0.1.tgz is a source installation of the readline module that downloads readline from gnu.org, compiles a static readline, and links Python with it.. therefore it does not depend on fink or a developer tools installation. A binary installer could easily be created using this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776602&group_id=5470 From noreply@sourceforge.net Thu Jul 24 02:47:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 18:47:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-776181 ] Small typo in reference for __ixor__ Message-ID: Bugs item #776181, was opened at 2003-07-23 07:02 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776181&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Francesco Ricciardi (nerby) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Small typo in reference for __ixor__ Initial Comment: In chapter 3.3.6 'Emulating numeric types' of the HTML version of the Reference Manual, in the description of the augmented arithmetic operators, the second to last symbol is '=' instead of '^='. This is true for various Python versions, but only for the HTML code (PDF and Postscript do have '^='). ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-23 21:47 Message: Logged In: YES user_id=3066 Fix backported to Doc/ref/ref3.tex revision 1.82.4.10. Closing this report. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-07-23 11:19 Message: Logged In: YES user_id=3066 Fixed for Python 2.3 in Doc/ref/ref3.tex revision 1.114. Should be backported; leaving this report open until that's done, but marking as Fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776181&group_id=5470 From noreply@sourceforge.net Thu Jul 24 04:51:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 20:51:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-773286 ] nconsistant results for os.listdir,os.path.isdir on W2k Message-ID: Bugs item #773286, was opened at 2003-07-17 16:36 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773286&group_id=5470 Category: Python Library Group: Python 2.2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Richard F. Emerson (remerson) Assigned to: Nobody/Anonymous (nobody) Summary: nconsistant results for os.listdir,os.path.isdir on W2k Initial Comment: Inconsistant results when using os.listdir,os.path.isdir and os.path.isfile on the win200 platform. Run the following script and compare with a directroy view. They do not match for the second directory of the two. """ to separate the sub directories from the files in a directory""" import os p1=os.getcwd() x=os.listdir(p1) p2= os.path.join("c:\","python~1","Tools") y=os.listdir(p2) #cwd = os.path.join("c:\") #cwd=cwd+"\doc\" #cwd="c:\python~1\Doc" #cwd=cwd+"\Qualcomm"+"\Eduora" #print x,y print "path",p1,"\n" print "directories","\n" for item in x: #print item if os.path.isdir(item): print " ",item print "\n","files","\n" for item in os.listdir(cwd): if os.path.isfile(item): print " ",item print "path",p2,"\n" print "directories","\n" for item in y: #print item if os.path.isdir(item): print " ",item print "\n","files","\n" for item in os.listdir(cwd): if os.path.isfile(item): print " ",item the lists x and y do contain all the file and directory names and one would expect the same sorting of both lists into directories only and files only. Not so on my machine. Results path C:\PYTHON~1 directories DLLs Doc include Lib libs Qualcomm tcl Tools files Circle.py Circle.pyc INSTALL.LOG LICENSE.txt log.bak Log.py Log.pyc mailspin.py mailspin.pyc mailspin1.py NEWS.txt py.ico pyc.ico pycon.ico python.exe pythonw.exe README.txt Requirements for the Message Separator.doc session.txt test dirs.py test dirs1.py test file.txt w9xpopen.exe path c:\python~1\Tools directories files Circle.py Circle.pyc INSTALL.LOG LICENSE.txt log.bak Log.py Log.pyc mailspin.py mailspin.pyc mailspin1.py NEWS.txt py.ico pyc.ico pycon.ico python.exe pythonw.exe README.txt Requirements for the Message Separator.doc session.txt test dirs.py test dirs1.py test file.txt w9xpopen.exe The tools sub directory is as delivered with the distribution. The Python~1 directory has had a few files added. Though I am new to Python, I tried locating the functions or classes that implemented the dirlist, isdir and isfile with only limited success. I looked in os, os.path and ntpath. I can be reached by phone at 818.354.3848 if more immediate communications is required to understand the problem (mine or the library's ) and resolve it. Regards Dick ---------------------------------------------------------------------- Comment By: Richard F. Emerson (remerson) Date: 2003-07-23 18:36 Message: Logged In: YES user_id=824995 Recommend closing this bug as the vagueness lies in the documentation. Alternatively, return an error if the path provided is not an abspath. Either way the documentation should be updated. The library routines os.path.isdir() and os.path.isfile() require that the path argument be an abspath. In the absence of an abspath they use the cwd as the pbase path and prepend it to the data found with the os.listdir() request. Hence it works for the first case I tried bu not the second, yet it doesnt complain. Thanks for your rapid response. Checking into the questions asked led to the solution. Regards Dick ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-17 21:11 Message: Logged In: YES user_id=80475 What is the issue? * Is it a matter of os.listdir() having a sort order different from that shown by another windows tool? If so, then that is not a bug (the sort order is not guaranteed by the underlying o.s.). * Is there another tool that makes different idenfications of what is a directory vs what is a file? If so, please include a DOS listing of the file attributes ("attrib *.*") and a similar list from Python: for filename is os.listdir(p): print filename, os.isdir(filename), os.isfile(filename) * Is there any internal inconsistency within Python. If so, please show the comparative result. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773286&group_id=5470 From noreply@sourceforge.net Thu Jul 24 06:09:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 22:09:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-776721 ] locale.setlocale() leaks Message-ID: Bugs item #776721, was opened at 2003-07-24 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=776721&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: locale.setlocale() leaks Initial Comment: _locale.setlocale() leaks the 'saved' locale. The following code leaks memory without bound. import locale while 1: locale.setlocale(locale.LC_NUMERIC, 'us') Attaching a patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776721&group_id=5470 From noreply@sourceforge.net Thu Jul 24 06:20:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 23 Jul 2003 22:20:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-776721 ] locale.setlocale() leaks Message-ID: Bugs item #776721, was opened at 2003-07-24 15:09 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776721&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: locale.setlocale() leaks Initial Comment: _locale.setlocale() leaks the 'saved' locale. The following code leaks memory without bound. import locale while 1: locale.setlocale(locale.LC_NUMERIC, 'us') Attaching a patch ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-07-24 15:20 Message: Logged In: YES user_id=14198 Actually, I also noticed another potential error - the wrong variable is checked for NULL, so a memory error could also kill us. Attaching a new patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776721&group_id=5470 From noreply@sourceforge.net Thu Jul 24 09:00:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Jul 2003 01:00:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-776805 ] Bug in float objects Message-ID: Bugs item #776805, was opened at 2003-07-24 16: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=776805&group_id=5470 Category: Python Library Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mukhsein Johari (mukhsein) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in float objects Initial Comment: There seems to be a bug in floats. This is present in 2.2.1 through 2.2.3 - don't know about 2.3. It exists in Linux Mandrake and Red Hat and FreeBSD. On P3, P4 and Athlon. Tests like: 0.4+0.2 <= 0.6 evals to 0 See the following for details: Python 2.2.3 (#1, Jul 24 2003, 12:44:45) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> 0.1 0.10000000000000001 >>> 0.11 0.11 >>> 0.12 0.12 >>> 0.2 0.20000000000000001 >>> 0.3 0.29999999999999999 >>> 0.4 0.40000000000000002 >>> 0.5 0.5 >>> 0.6 0.59999999999999998 >>> 0.7 0.69999999999999996 >>> 0.8 0.80000000000000004 >>> 0.9 0.90000000000000002 >>> 0.10 0.10000000000000001 >>> 0.1000 0.10000000000000001 >>> 0.3 0.29999999999999999 >>> 0.03 0.029999999999999999 >>> 0.003 0.0030000000000000001 >>> 0.0003 0.00029999999999999997 >>> print 0.1 0.1 >>> print 0.2 0.2 >>> print 0.3 0.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776805&group_id=5470 From noreply@sourceforge.net Thu Jul 24 13:50:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Jul 2003 05:50:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-776721 ] locale.setlocale() leaks Message-ID: Bugs item #776721, was opened at 2003-07-24 01:09 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776721&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open >Resolution: Accepted Priority: 7 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: locale.setlocale() leaks Initial Comment: _locale.setlocale() leaks the 'saved' locale. The following code leaks memory without bound. import locale while 1: locale.setlocale(locale.LC_NUMERIC, 'us') Attaching a patch ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-24 08:50 Message: Logged In: YES user_id=12800 Mark, please check this in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-24 01:20 Message: Logged In: YES user_id=14198 Actually, I also noticed another potential error - the wrong variable is checked for NULL, so a memory error could also kill us. Attaching a new patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776721&group_id=5470 From noreply@sourceforge.net Thu Jul 24 14:28:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Jul 2003 06:28:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-776805 ] Bug in float objects Message-ID: Bugs item #776805, was opened at 2003-07-24 08:00 Message generated for change (Comment added) made by nascheme You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776805&group_id=5470 Category: Python Library Group: Python 2.2.3 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Mukhsein Johari (mukhsein) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in float objects Initial Comment: There seems to be a bug in floats. This is present in 2.2.1 through 2.2.3 - don't know about 2.3. It exists in Linux Mandrake and Red Hat and FreeBSD. On P3, P4 and Athlon. Tests like: 0.4+0.2 <= 0.6 evals to 0 See the following for details: Python 2.2.3 (#1, Jul 24 2003, 12:44:45) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> 0.1 0.10000000000000001 >>> 0.11 0.11 >>> 0.12 0.12 >>> 0.2 0.20000000000000001 >>> 0.3 0.29999999999999999 >>> 0.4 0.40000000000000002 >>> 0.5 0.5 >>> 0.6 0.59999999999999998 >>> 0.7 0.69999999999999996 >>> 0.8 0.80000000000000004 >>> 0.9 0.90000000000000002 >>> 0.10 0.10000000000000001 >>> 0.1000 0.10000000000000001 >>> 0.3 0.29999999999999999 >>> 0.03 0.029999999999999999 >>> 0.003 0.0030000000000000001 >>> 0.0003 0.00029999999999999997 >>> print 0.1 0.1 >>> print 0.2 0.2 >>> print 0.3 0.3 ---------------------------------------------------------------------- >Comment By: Neil Schemenauer (nascheme) Date: 2003-07-24 13:28 Message: Logged In: YES user_id=35752 It's no a bug. See http://www.python.org/doc/current/tut/node14.html. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776805&group_id=5470 From noreply@sourceforge.net Thu Jul 24 15:15:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Jul 2003 07:15:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-776721 ] locale.setlocale() leaks Message-ID: Bugs item #776721, was opened at 2003-07-24 15:09 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776721&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: locale.setlocale() leaks Initial Comment: _locale.setlocale() leaks the 'saved' locale. The following code leaks memory without bound. import locale while 1: locale.setlocale(locale.LC_NUMERIC, 'us') Attaching a patch ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-07-25 00:15 Message: Logged In: YES user_id=14198 Checking in _localemodule.c; new revision: 2.40; previous revision: 2.39 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-24 22:50 Message: Logged In: YES user_id=12800 Mark, please check this in. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-24 15:20 Message: Logged In: YES user_id=14198 Actually, I also noticed another potential error - the wrong variable is checked for NULL, so a memory error could also kill us. Attaching a new patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776721&group_id=5470 From noreply@sourceforge.net Thu Jul 24 21:42:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Jul 2003 13:42:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-777188 ] space re accepts newline Message-ID: Bugs item #777188, was opened at 2003-07-24 13: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=777188&group_id=5470 Category: Regular Expressions Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: Matthew R. Wette (mwette) Assigned to: Fredrik Lundh (effbot) Summary: space re accepts newline Initial Comment: If my understanding of re is not wrong, the regular expression r'\s+' should not accept newline. The following code prints "re broken" #!/usr/bin/env python import re s = "\n" x = re.compile("\s+") m = x.match(s) if m: print "re broken" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777188&group_id=5470 From noreply@sourceforge.net Thu Jul 24 21:59:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Jul 2003 13:59:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-777188 ] space re accepts newline Message-ID: Bugs item #777188, was opened at 2003-07-24 13:42 Message generated for change (Comment added) made by mwette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777188&group_id=5470 Category: Regular Expressions Group: Python 2.2 >Status: Deleted Resolution: None Priority: 5 Submitted By: Matthew R. Wette (mwette) Assigned to: Fredrik Lundh (effbot) Summary: space re accepts newline Initial Comment: If my understanding of re is not wrong, the regular expression r'\s+' should not accept newline. The following code prints "re broken" #!/usr/bin/env python import re s = "\n" x = re.compile("\s+") m = x.match(s) if m: print "re broken" ---------------------------------------------------------------------- >Comment By: Matthew R. Wette (mwette) Date: 2003-07-24 13:59 Message: Logged In: YES user_id=829837 I just read the manual more carefully. I was wrong. \s includes newline. Sorry! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777188&group_id=5470 From noreply@sourceforge.net Thu Jul 24 22:08:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Jul 2003 14:08:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-777188 ] space re accepts newline Message-ID: Bugs item #777188, was opened at 2003-07-24 16: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=777188&group_id=5470 Category: Regular Expressions >Group: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Matthew R. Wette (mwette) Assigned to: Fredrik Lundh (effbot) Summary: space re accepts newline Initial Comment: If my understanding of re is not wrong, the regular expression r'\s+' should not accept newline. The following code prints "re broken" #!/usr/bin/env python import re s = "\n" x = re.compile("\s+") m = x.match(s) if m: print "re broken" ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-24 17:08 Message: Logged In: YES user_id=31435 Yup, \s matches all whitespace characters, including \n and \r. Thanks for following up! ---------------------------------------------------------------------- Comment By: Matthew R. Wette (mwette) Date: 2003-07-24 16:59 Message: Logged In: YES user_id=829837 I just read the manual more carefully. I was wrong. \s includes newline. Sorry! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777188&group_id=5470 From noreply@sourceforge.net Thu Jul 24 23:25:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Jul 2003 15:25:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-776533 ] Carbon.Snd module SPB constructor shadowed Message-ID: Bugs item #776533, was opened at 2003-07-23 23:20 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776533&group_id=5470 Category: Macintosh Group: None Status: Open >Resolution: Later Priority: 5 Submitted By: Marcus Mendenhall (mendenhall) Assigned to: Jack Jansen (jackjansen) Summary: Carbon.Snd module SPB constructor shadowed Initial Comment: I recently found an apparent bug in the automatically generated wrappers for Carbon.Snd. There is a name conflict over SPB, which is both declared as a type object, and as a constructor for an SPB. The type object is shadowing the SPB constructor, so it is impossible to build SPBs, and thus impossible to do much with the module. There are two names for the SPB data type -- SPB and SPBType, generated by the wrapper generator. The SPBType should probably be kept, while SPB() should be unshadowed to allow creation of SPBs. The error can be trivially replicated by just importing Carbon.Snd and attempting to create an SPB with a=Snd.SPB(), which returns an error. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-25 00:25 Message: Logged In: YES user_id=45365 I've manually edited _Sndmodule.c to get rid of the SPB name for SPBType. This is a stopgap for the 2.3 distribution, eventually the fix will have to be in sndgen.py, but at least that should make Carbon.Snd work again for 2.3rc2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776533&group_id=5470 From noreply@sourceforge.net Fri Jul 25 04:03:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 24 Jul 2003 20:03:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-583975 ] gethostbyaddr lag Message-ID: Bugs item #583975, was opened at 2002-07-19 12:41 Message generated for change (Comment added) made by jasonrm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Mastaler (jasonrm) Assigned to: Nobody/Anonymous (nobody) Summary: gethostbyaddr lag Initial Comment: For more info, also see http://mail.python.org/pipermail/python-list/2002-July/113706.html Perl's gethostbyaddr doesn't seem to have this problem as shown below. Should I report this in the bug tracker? $ time perl -MSocket -lwe 'print +(gethostbyaddr inet_aton("datavortex.net"), AF_INET)[0]' datavortex.net real 0m0.063s user 0m0.050s sys 0m0.010s $ time python2 -c 'from socket import * ; print gethostbyaddr("datavortex.net")[0]' datavortex.net real 0m20.176s user 0m0.070s sys 0m0.020s ---------------------------------------------------------------------- >Comment By: Jason R. Mastaler (jasonrm) Date: 2003-07-24 21:03 Message: Logged In: YES user_id=85984 This problem has cropped up again for another TMDA user, so we still have this bug in Python. In short, just as with the previous report, this user sees a 20 second delay with socket.gethostbyaddr() on a hostname which all other tools (nslookup, host, mail progs, etc) look up instantaneously. In other words, Python is the only app on his system with this problem. I had him try Python 2.3c1 to no avail. As with the previous user, he is running Linux (Redhat): Linux sparge 2.4.20-18.7 #1 Thu May 29 06:51:53 EDT 2003 i686 unknown glibc-2.2.5-43 Any other information I should provide or any diagnostics I can have the user run? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-11-02 21:40 Message: Logged In: YES user_id=85984 The problem was under Python 2.2. Though now the user reports that he can no longer reproduce the problem, despite not having done any Python upgrades or system configuration changes. We might just have to chuck this one up to FM (Funny Magic). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-11-02 14:14 Message: Logged In: YES user_id=33168 Jason, still with us? What version of python were you having the problem with? 2.1.x? 2.2.x? Do you have the problem with 2.2? Have you looked at patch #604210 (http://python.org/604210)? Can you test that? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-09-06 18:20 Message: Logged In: YES user_id=85984 Still having the problem, but I'm unsure how to proceed. nslookup and host both return instantly when querying datavortex.net. Only Python seems to exhibit this problem, but it still could be a system misconfiguration. This is the only time I've ever seen/heard of this behavior. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-06 16:23 Message: Logged In: YES user_id=33168 Jason, are you still having this problem? Do you have anything to report? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-22 16:37 Message: Logged In: YES user_id=33168 Looking at the output, the problem is definitely in gethostbyaddr_r(). This is what python calls from Modules/socketmodule.c socket_gethostbyaddr(). Notice: the first attempt to send to the first DNS server "207.69.188.185" looks like it fails after 5 seconds. DNS #2 is attempted "207.69.188.186", this send also takes 5 seconds, back to #1 ... The poll is being done in gethostbyaddr_r() (ie, libc). If you want to break in a debugger, gethost...() should be around line 2216 in python 2.2. You can also put prints in. As for why perl doesn't have the same problem, it could be that perl doesn't use the same library call (gethostbyaddr_r), or attempts to read from /etc/hosts before contacting the DNS server. I'm just guessing. In order to debug this further, you will probably need the python sources. What happens if you do host datavortex.net (you could also try nslookup)? Does that return immediately or wait? ---------------------------------------------------------------------- Comment By: Data Vortex (datavortex) Date: 2002-07-22 13:15 Message: Logged In: YES user_id=141979 Running strace python2 -c 'from socket import * ; print getfqdn()', I can see a pause of several seconds during the output of: socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\351\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\0\0\34\0\1", 32, 0) = 32 gettimeofday({1027364850, 154497}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, ")\351\201\200\0\1\0\0\0\1\0\0\ndatavortex\3net\0\0\34\0"..., 1024, 0, {sin_family=AF_INET, sin_p ort=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 95 close(3) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3 connect(3, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.185")}}, 28) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364850, 169212}, NULL) = 0 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 connect(4, {sin_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("207.69.188.186")}}, 28) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364855, 172955}, NULL) = 0 poll([{fd=4, events=POLLIN}], 1, 5000) = 0 send(3, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364860, 182024}, NULL) = 0 poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1 recvfrom(3, "<\310\201\202\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 1024, 0, {sin_family=AF_INET, sin_por t=htons(53), sin_addr=inet_addr("207.69.188.185")}}, [16]) = 36 poll([{fd=3, events=POLLIN}], 1, 5000) = 0 send(4, ")\352\1\0\0\1\0\0\0\0\0\0\ndatavortex\3net\3net\0"..., 36, 0) = 36 gettimeofday({1027364865, 191273}, NULL) = 0 The full output of this command is availible here: http://datavortex.net/out.txt ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 15:09 Message: Logged In: YES user_id=33168 That's a good idea Jack. On Linux, you can use strace. On Solaris, I believe the program is called truss. $ strace python ... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-20 15:03 Message: Logged In: YES user_id=45365 Here's a few ideas on debugging this: - Easiest would be if you have a system call tracer. Attach it to the process and see during what system call the 20 second wait occurs. Then look at it's parameters and see whether there's anything fishy. Or whether you can recreate the problem in C. - If you don't have a tracer first split the program in two steps: the implicit gethostbyname() step and the gethostbyaddr() step. see which one is the problem. Run this step under the debugger and see where the delay is. Again, try to recreate the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-07-20 10:02 Message: Logged In: YES user_id=33168 Does this happen consistently (every run) or only the first time? Works fine for me (Linux). What OS are you on? ---------------------------------------------------------------------- Comment By: Jason R. Mastaler (jasonrm) Date: 2002-07-19 15:46 Message: Logged In: YES user_id=85984 I'm not ruling it out that it could be a local configuration problem, it's just that Python is the only application experiencing this delay. We've gone through the network configuration and everything seems sound, so I'm not sure what more to do. /etc/resolv.conf is fine -- all entries are operational nameservers. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2002-07-19 15:42 Message: Logged In: YES user_id=45365 This smells like a local configuration bug on your system, on my system it works fine (0.220u 0.110s 0:01.85 17.8% 0+0k 84+10io 0pf+0w). Look in your /etc/resolv.conf (or similar file for your platform) to see that there aren't any non-existing hosts listed there. Although, of course, that doesn't explain why perl has no delay... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=583975&group_id=5470 From noreply@sourceforge.net Fri Jul 25 13:57:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 05:57:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 20:21 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 12:57 Message: Logged In: YES user_id=52562 I don't know if this is important, but I still can't build the bsddb3 module on my system without manually editing my /etc/ld.so.conf, and even after I do manually edit my /etc/ld.so.conf the tests seem to fail. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-23 12:59 Message: Logged In: YES user_id=52562 Could you tell me how to find out why distutils doesn't use the -R/-rpath option? Could it be that it assumes /usr/local/lib is already going to be in the ld path? By the way, having manually added /usr/local/lib to my /etc/ld.so.conf, it compiles with no errors, but make test yields the following: HACK pion:~/playground/python/python/dist/src$ grep -i -E --regex="bsddb|berk|db[^A-Za-z]" /tmp/zooko/logs/make.test.python test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd Is that right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 21:05 Message: Logged In: YES user_id=21627 Ok. Can you try to find out why distutils fails to use the -R/-rpath option? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 21:02 Message: Logged In: YES user_id=52562 Okay, I've tried these. -Wl,verbose tells me, as I expected: attempt to open /usr/local/stow/python-g/lib/libdb-4.1.so failed attempt to open /usr/local/stow/python-g/lib/libdb-4.1.a failed attempt to open /usr/local/lib/libdb-4.1.so succeeded -ldb-4.1 (/usr/local/lib/libdb-4.1.so) nm tells me, as expected, that db_create is present: MAIL pion:~$ nm /usr/local/lib/libdb-4.1.so | grep db_create 0001a554 T __bam_db_create 000783cc T __ham_db_create 000a5fe0 T __qam_db_create 000492c8 T db_create Adding /usr/local/lib to my /etc/ld.so.conf and running ldconfig *did* fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 20:41 Message: Logged In: YES user_id=21627 Please collect the following information: 1. Invoke the linker line with -Wl,--verbose (manually), to find out the path it uses for the -ldb-4.1 command line option. In particular, find out whether it uses a shared or static library (.so or .a) 2. Perform nm on that library|grep db_create The symbol really should be there; it is on all copies of -ldb-something that I can get hold of. If it is not in your copy, you somehow messed up the BerkeleyDB build. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 20:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 20:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Fri Jul 25 15:28:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 07:28:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 20:21 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 14:28 Message: Logged In: YES user_id=52562 Here's some more details about my system: * Debian unstable/testing * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * GNU Make 3.80 * AMD Athlon XP 1600+ ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 12:57 Message: Logged In: YES user_id=52562 I don't know if this is important, but I still can't build the bsddb3 module on my system without manually editing my /etc/ld.so.conf, and even after I do manually edit my /etc/ld.so.conf the tests seem to fail. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-23 12:59 Message: Logged In: YES user_id=52562 Could you tell me how to find out why distutils doesn't use the -R/-rpath option? Could it be that it assumes /usr/local/lib is already going to be in the ld path? By the way, having manually added /usr/local/lib to my /etc/ld.so.conf, it compiles with no errors, but make test yields the following: HACK pion:~/playground/python/python/dist/src$ grep -i -E --regex="bsddb|berk|db[^A-Za-z]" /tmp/zooko/logs/make.test.python test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd Is that right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 21:05 Message: Logged In: YES user_id=21627 Ok. Can you try to find out why distutils fails to use the -R/-rpath option? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 21:02 Message: Logged In: YES user_id=52562 Okay, I've tried these. -Wl,verbose tells me, as I expected: attempt to open /usr/local/stow/python-g/lib/libdb-4.1.so failed attempt to open /usr/local/stow/python-g/lib/libdb-4.1.a failed attempt to open /usr/local/lib/libdb-4.1.so succeeded -ldb-4.1 (/usr/local/lib/libdb-4.1.so) nm tells me, as expected, that db_create is present: MAIL pion:~$ nm /usr/local/lib/libdb-4.1.so | grep db_create 0001a554 T __bam_db_create 000783cc T __ham_db_create 000a5fe0 T __qam_db_create 000492c8 T db_create Adding /usr/local/lib to my /etc/ld.so.conf and running ldconfig *did* fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 20:41 Message: Logged In: YES user_id=21627 Please collect the following information: 1. Invoke the linker line with -Wl,--verbose (manually), to find out the path it uses for the -ldb-4.1 command line option. In particular, find out whether it uses a shared or static library (.so or .a) 2. Perform nm on that library|grep db_create The symbol really should be there; it is on all copies of -ldb-something that I can get hold of. If it is not in your copy, you somehow messed up the BerkeleyDB build. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 20:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 20:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Fri Jul 25 15:43:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 07:43:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-777588 ] asyncore is broken for windows if connection is refused Message-ID: Bugs item #777588, was opened at 2003-07-25 14:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777588&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore is broken for windows if connection is refused Initial Comment: asyncore.poll is broken on windows. If a connection is refused happens it will hang for ever and never raise an exception. The Select statment never checks the exfds. This is needed as this is where windows reports failed connections. The documentation in the microsoft platform SDK mentions this. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/select_2.asp The suggested fix is shown below althought this is untested. The correct error number is recived from getsockopt(SOL_SOCKET,SO_ERROR) def poll(timeout=0.0, map=None): if map is None: map = socket_map if map: r = []; w = []; e = [] for fd, obj in map.items(): if obj.readable(): r.append(fd) if obj.writable(): w.append(fd) if sys.platform == 'win32': if not obj.connected: e.append(fd) if [] == r == w == e: time.sleep(timeout) else: try: r, w, e = select.select(r, w, e, timeout) except select.error, err: if err[0] != EINTR: raise else: return if sys.platform == 'win32': for fd in e: obj = map.get(fd) if obj is None: continue errno = fs.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) raise socket.error,(errno,socketerrorTab[error]) for fd in r: obj = map.get(fd) if obj is None: continue read(obj) for fd in w: obj = map.get(fd) if obj is None: continue write(obj) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777588&group_id=5470 From noreply@sourceforge.net Fri Jul 25 16:01:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 08:01:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-777597 ] socketmodule.c connection handling incorect on windows Message-ID: Bugs item #777597, was opened at 2003-07-25 15:01 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777597&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c connection handling incorect on windows Initial Comment: The socketmodule.c code does not handle connection refused correctly. This is due to a different of operation on windows of select. The offending code is in internal_connect in the MS_WINDOWS ifdef. The code in should test exceptfds to check for connecttion refused. If this is so itshould call getsockopt(SOL_SOCKET, SO_ERROR,..) to get the error status. (Source microsoft Platform SDK) The suggested fix is shown below (untested) #ifdef MS_WINDOWS f (s->sock_timeout > 0.0) { if (res < 0 && WSAGetLastError() == WSAEWOULDBLOCK) { /* This is a mess. Best solution: trust select */ fd_set exfds; struct timeval tv; tv.tv_sec = (int)s->sock_timeout; tv.tv_usec = (int)((s->sock_timeout - tv.tv_sec) * 1e6); FD_ZERO(&exfds); FD_SET(s->sock_fd, &exfds); /* Platform SDK says so */ res = select(s->sock_fd+1, NULL, NULL, &exfds, &tv); if (res > 0) { if( FD_ISSET( &exfds ) ) { /* Get the real reason */ getsockopt(s->sock_fd,SOL_SOCKET,SO_ERROR,(char*)&res,sizeof(res)); } else { /* God knows how we got here */ res = 0; } } else if( res == 0 ) { res = WSAEWOULDBLOCK; } else { /* Not sure we should return the erro from select? */ res = WSAGetLastError(); } } } else if (res < 0) res = WSAGetLastError(); #else ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777597&group_id=5470 From noreply@sourceforge.net Fri Jul 25 16:35:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 08:35:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-772787 ] right button context 'edit with idle' Message-ID: Bugs item #772787, was opened at 2003-07-17 04:36 Message generated for change (Comment added) made by nestor5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None >Priority: 4 Submitted By: nestor (nestor5) Assigned to: Nobody/Anonymous (nobody) Summary: right button context 'edit with idle' Initial Comment: after installing Python 2.3b2 under windows, the right mouse button context option in windows explorer 'edit with idle' on *.py files ceased to work on two mashines (I upgraded from python b1 to b2). One was Windows 2000 and one was Windows XP. Installation is default C:\python23 installation. ---------------------------------------------------------------------- >Comment By: nestor (nestor5) Date: 2003-07-25 15:35 Message: Logged In: YES user_id=793384 these seem to be fixed in Python 2.3c2. Can you confirm this tebeka? So we can close this bug? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 15:36 Message: Logged In: YES user_id=31435 On Win2K I can't reproduce tebeka's problem with the instructions as given. But I get a frozen window if I repeat the last two steps. o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" o Right click on another .py file o Choose "Edit with IDLE" ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 07:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 07:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 From noreply@sourceforge.net Fri Jul 25 17:44:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 09:44:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-777664 ] HIDDEN in Tkconstants.py Message-ID: Bugs item #777664, was opened at 2003-07-25 16: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=777664&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Smith (johnjsmith) Assigned to: Nobody/Anonymous (nobody) Summary: HIDDEN in Tkconstants.py Initial Comment: Python: 2.3rc2 HIDDEN = 'hidden' should be there in Tkconstants.py (it's used in the canvas). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777664&group_id=5470 From noreply@sourceforge.net Fri Jul 25 17:39:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 09:39:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-777659 ] Uninitialized variable used in Tools/faqwiz/faqwiz.py Message-ID: Bugs item #777659, was opened at 2003-07-25 16: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=777659&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Smith (johnjsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Uninitialized variable used in Tools/faqwiz/faqwiz.py Initial Comment: Python: 2.3rc2 The uninitialized variable tfn is used in Tools/faqwiz/faqwiz.py (lines 811, 833). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777659&group_id=5470 From noreply@sourceforge.net Fri Jul 25 16:44:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 08:44:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-772787 ] right button context 'edit with idle' Message-ID: Bugs item #772787, was opened at 2003-07-17 00:36 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: nestor (nestor5) Assigned to: Nobody/Anonymous (nobody) Summary: right button context 'edit with idle' Initial Comment: after installing Python 2.3b2 under windows, the right mouse button context option in windows explorer 'edit with idle' on *.py files ceased to work on two mashines (I upgraded from python b1 to b2). One was Windows 2000 and one was Windows XP. Installation is default C:\python23 installation. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-25 11:44 Message: Logged In: YES user_id=31435 The original bug is fixed, but the other bug reported by tebeka in a comment has not been fixed. It would help if tebeka opened a new bug report for that, so it's clearly identifed in the system as a distinct bug. ---------------------------------------------------------------------- Comment By: nestor (nestor5) Date: 2003-07-25 11:35 Message: Logged In: YES user_id=793384 these seem to be fixed in Python 2.3c2. Can you confirm this tebeka? So we can close this bug? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 11:36 Message: Logged In: YES user_id=31435 On Win2K I can't reproduce tebeka's problem with the instructions as given. But I get a frozen window if I repeat the last two steps. o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" o Right click on another .py file o Choose "Edit with IDLE" ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 03:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 03:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 From noreply@sourceforge.net Fri Jul 25 18:27:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 10:27:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-764049 ] pythonw crashes under one windows platform (easy-everything) Message-ID: Bugs item #764049, was opened at 2003-07-01 16:47 Message generated for change (Comment added) made by angelpeream You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764049&group_id=5470 Category: Windows Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Angel Perea Martinez (angelpeream) Assigned to: Nobody/Anonymous (nobody) Summary: pythonw crashes under one windows platform (easy-everything) Initial Comment: pythonw (Python 2.3b2 (#43, Jun 29 2003, 16:43:04)) crashes (performs an invalid operation) under some special windows platform (easy-everything internet-cafe PCs). Previous versions showed no problem. Not surely a bug, but disencourages trying the language. ---------------------------------------------------------------------- >Comment By: Angel Perea Martinez (angelpeream) Date: 2003-07-25 17:27 Message: Logged In: YES user_id=606911 I couldnt dig in it. That platform has proved not very... cooperative, but it does'nt happen in 2.3c2 anymore, so, whatever it was, got fixed. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-02 04:06 Message: Logged In: YES user_id=80475 Do you have any idea of where it crashes? Can you dig in to it and find out which verison in CVS is the first to not run? Otherwise, it is like Tim says, the bug report is equilavent of saying the something appears wrong on the dark side of the moon. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-01 17:19 Message: Logged In: YES user_id=31435 Unassigned. If someone with access to such a platform doesn't dig into this, it appears hopeless. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764049&group_id=5470 From noreply@sourceforge.net Sat Jul 26 00:25:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 16:25:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-777867 ] test_ioctl fails Message-ID: Bugs item #777867, was opened at 2003-07-25 23:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 From noreply@sourceforge.net Sat Jul 26 00:33:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 16:33:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-777867 ] test_ioctl fails Message-ID: Bugs item #777867, was opened at 2003-07-25 23:25 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 23:33 Message: Logged In: YES user_id=52562 The stuff I posted when I opened this bug report was all from running "make test". I have now discovered the "regrtest.py" file and am experimenting with it. -s doesn't seem to work for test_ioctl.py: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py -v -s ./Lib/test/test_ioctl.py ./Lib/test/test_ioctl test ./Lib/test/test_ioctl crashed -- exceptions.ValueError: Empty module name Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) ValueError: Empty module name 1 test failed: ./Lib/test/test_ioctl Traceback (most recent call last): File "./Lib/test/regrtest.py", line 1005, in ? main() File "./Lib/test/regrtest.py", line 332, in main os.unlink(filename) OSError: [Errno 2] No such file or directory: '/tmp/pynexttest' But running regrtest.py by itself runs a bunch of tests including test_ioctl, apparently successfully: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py ... test_ioctl ... 224 tests OK. 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale So I guess this is an "issue" in the make target rather than in the ioctl code itself... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 From noreply@sourceforge.net Sat Jul 26 00:33:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 16:33:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-777867 ] test_ioctl fails Message-ID: Bugs item #777867, was opened at 2003-07-26 00:25 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-07-26 00:33 Message: Logged In: YES user_id=6656 Can you dig? I.e. more info than "test_ioctl fails"... try running the code that test_ioctl runs and see what that does ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 00:33 Message: Logged In: YES user_id=52562 The stuff I posted when I opened this bug report was all from running "make test". I have now discovered the "regrtest.py" file and am experimenting with it. -s doesn't seem to work for test_ioctl.py: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py -v -s ./Lib/test/test_ioctl.py ./Lib/test/test_ioctl test ./Lib/test/test_ioctl crashed -- exceptions.ValueError: Empty module name Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) ValueError: Empty module name 1 test failed: ./Lib/test/test_ioctl Traceback (most recent call last): File "./Lib/test/regrtest.py", line 1005, in ? main() File "./Lib/test/regrtest.py", line 332, in main os.unlink(filename) OSError: [Errno 2] No such file or directory: '/tmp/pynexttest' But running regrtest.py by itself runs a bunch of tests including test_ioctl, apparently successfully: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py ... test_ioctl ... 224 tests OK. 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale So I guess this is an "issue" in the make target rather than in the ioctl code itself... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 From noreply@sourceforge.net Sat Jul 26 00:44:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 16:44:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-777867 ] test_ioctl fails Message-ID: Bugs item #777867, was opened at 2003-07-25 23:25 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 23:44 Message: Logged In: YES user_id=52562 I cut and pasted the unit test code and ran it, and it passed. So I suppose it's a bug in how "make test" invokes the test_ioctl unit test? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-25 23:33 Message: Logged In: YES user_id=6656 Can you dig? I.e. more info than "test_ioctl fails"... try running the code that test_ioctl runs and see what that does ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 23:33 Message: Logged In: YES user_id=52562 The stuff I posted when I opened this bug report was all from running "make test". I have now discovered the "regrtest.py" file and am experimenting with it. -s doesn't seem to work for test_ioctl.py: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py -v -s ./Lib/test/test_ioctl.py ./Lib/test/test_ioctl test ./Lib/test/test_ioctl crashed -- exceptions.ValueError: Empty module name Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) ValueError: Empty module name 1 test failed: ./Lib/test/test_ioctl Traceback (most recent call last): File "./Lib/test/regrtest.py", line 1005, in ? main() File "./Lib/test/regrtest.py", line 332, in main os.unlink(filename) OSError: [Errno 2] No such file or directory: '/tmp/pynexttest' But running regrtest.py by itself runs a bunch of tests including test_ioctl, apparently successfully: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py ... test_ioctl ... 224 tests OK. 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale So I guess this is an "issue" in the make target rather than in the ioctl code itself... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 From noreply@sourceforge.net Sat Jul 26 01:22:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 17:22:23 -0700 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 19:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777884&group_id=5470 Category: XML Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mark Lesh (leshmark) Assigned to: Nobody/Anonymous (nobody) 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777884&group_id=5470 From noreply@sourceforge.net Sat Jul 26 01:23:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 17:23:08 -0700 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 19:22 Message generated for change (Settings changed) made by leshmark 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: Nobody/Anonymous (nobody) >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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777884&group_id=5470 From noreply@sourceforge.net Sat Jul 26 00:52:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 16:52:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-777867 ] test_ioctl fails Message-ID: Bugs item #777867, was opened at 2003-07-26 00:25 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-07-26 00:52 Message: Logged In: YES user_id=6656 Oh dear. Could you hack 'make test' to pass -v to regrtest? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 00:44 Message: Logged In: YES user_id=52562 I cut and pasted the unit test code and ran it, and it passed. So I suppose it's a bug in how "make test" invokes the test_ioctl unit test? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-26 00:33 Message: Logged In: YES user_id=6656 Can you dig? I.e. more info than "test_ioctl fails"... try running the code that test_ioctl runs and see what that does ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 00:33 Message: Logged In: YES user_id=52562 The stuff I posted when I opened this bug report was all from running "make test". I have now discovered the "regrtest.py" file and am experimenting with it. -s doesn't seem to work for test_ioctl.py: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py -v -s ./Lib/test/test_ioctl.py ./Lib/test/test_ioctl test ./Lib/test/test_ioctl crashed -- exceptions.ValueError: Empty module name Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) ValueError: Empty module name 1 test failed: ./Lib/test/test_ioctl Traceback (most recent call last): File "./Lib/test/regrtest.py", line 1005, in ? main() File "./Lib/test/regrtest.py", line 332, in main os.unlink(filename) OSError: [Errno 2] No such file or directory: '/tmp/pynexttest' But running regrtest.py by itself runs a bunch of tests including test_ioctl, apparently successfully: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py ... test_ioctl ... 224 tests OK. 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale So I guess this is an "issue" in the make target rather than in the ioctl code itself... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 From noreply@sourceforge.net Fri Jul 25 23:43:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 15:43:42 -0700 Subject: [Python-bugs-list] [ python-Bugs-777848 ] CGIHTTPServer and urls Message-ID: Bugs item #777848, was opened at 2003-07-26 00:41 Message generated for change (Settings changed) made by vincent_delft You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777848&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent delft (vincent_delft) >Assigned to: Raymond Hettinger (rhettinger) Summary: CGIHTTPServer and urls Initial Comment: If you have 2 differents CGI. On the both you ask to print the content of cgi.FieldStorage. You will see that URL paramters (after ? in the url) remains. For our example : 1) http://localhost:8080/cgi-bin/script1.py?action=test Will display the parameter name 'action' and his value 'test' BUT, now you ask the second url 2) http://localhost:8080/cgi-bin/script2.py you still see the previous parameter 'action' with the previous value 'test' I've resolve the problem by removing a test in the CGIHTTPServer.py script. line +- 149 - if query: - env['QUERY_STRING'] = query + env['QUERY_STRING'] = query Indeed, the os.environ.update(env) does not modify 'QUERY_STRING' if you are not givin a new value. But in this case empty is a new value, and must be take in account. I don't know if my resolution is the best one. But now it works like it should be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777848&group_id=5470 From noreply@sourceforge.net Fri Jul 25 23:41:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 15:41:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-777848 ] CGIHTTPServer and urls Message-ID: Bugs item #777848, was opened at 2003-07-26 00: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=777848&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent delft (vincent_delft) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer and urls Initial Comment: If you have 2 differents CGI. On the both you ask to print the content of cgi.FieldStorage. You will see that URL paramters (after ? in the url) remains. For our example : 1) http://localhost:8080/cgi-bin/script1.py?action=test Will display the parameter name 'action' and his value 'test' BUT, now you ask the second url 2) http://localhost:8080/cgi-bin/script2.py you still see the previous parameter 'action' with the previous value 'test' I've resolve the problem by removing a test in the CGIHTTPServer.py script. line +- 149 - if query: - env['QUERY_STRING'] = query + env['QUERY_STRING'] = query Indeed, the os.environ.update(env) does not modify 'QUERY_STRING' if you are not givin a new value. But in this case empty is a new value, and must be take in account. I don't know if my resolution is the best one. But now it works like it should be. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777848&group_id=5470 From noreply@sourceforge.net Fri Jul 25 22:46:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 14:46:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 22:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-25 23:46 Message: Logged In: YES user_id=21627 I now see what is happening. setup.py indeed expects that no additional configuration is needed for /usr/local/lib. If you had configured Sleepycat BSDDB in its standard location (/usr/local/BerkeleyDBx.y), setup.py would have added a -R option. Closing it as "won't fix". ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 16:28 Message: Logged In: YES user_id=52562 Here's some more details about my system: * Debian unstable/testing * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * GNU Make 3.80 * AMD Athlon XP 1600+ ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 14:57 Message: Logged In: YES user_id=52562 I don't know if this is important, but I still can't build the bsddb3 module on my system without manually editing my /etc/ld.so.conf, and even after I do manually edit my /etc/ld.so.conf the tests seem to fail. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-23 14:59 Message: Logged In: YES user_id=52562 Could you tell me how to find out why distutils doesn't use the -R/-rpath option? Could it be that it assumes /usr/local/lib is already going to be in the ld path? By the way, having manually added /usr/local/lib to my /etc/ld.so.conf, it compiles with no errors, but make test yields the following: HACK pion:~/playground/python/python/dist/src$ grep -i -E --regex="bsddb|berk|db[^A-Za-z]" /tmp/zooko/logs/make.test.python test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd Is that right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 23:05 Message: Logged In: YES user_id=21627 Ok. Can you try to find out why distutils fails to use the -R/-rpath option? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 23:02 Message: Logged In: YES user_id=52562 Okay, I've tried these. -Wl,verbose tells me, as I expected: attempt to open /usr/local/stow/python-g/lib/libdb-4.1.so failed attempt to open /usr/local/stow/python-g/lib/libdb-4.1.a failed attempt to open /usr/local/lib/libdb-4.1.so succeeded -ldb-4.1 (/usr/local/lib/libdb-4.1.so) nm tells me, as expected, that db_create is present: MAIL pion:~$ nm /usr/local/lib/libdb-4.1.so | grep db_create 0001a554 T __bam_db_create 000783cc T __ham_db_create 000a5fe0 T __qam_db_create 000492c8 T db_create Adding /usr/local/lib to my /etc/ld.so.conf and running ldconfig *did* fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 22:41 Message: Logged In: YES user_id=21627 Please collect the following information: 1. Invoke the linker line with -Wl,--verbose (manually), to find out the path it uses for the -ldb-4.1 command line option. In particular, find out whether it uses a shared or static library (.so or .a) 2. Perform nm on that library|grep db_create The symbol really should be there; it is on all copies of -ldb-something that I can get hold of. If it is not in your copy, you somehow messed up the BerkeleyDB build. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 22:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 22:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Sat Jul 26 07:16:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 25 Jul 2003 23:16:34 -0700 Subject: [Python-bugs-list] [ python-Bugs-777943 ] windll, calldll don't work in 2.3c2 Message-ID: Bugs item #777943, was opened at 2003-07-26 06: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=777943&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: james althoff (jamesalthoff) Assigned to: Nobody/Anonymous (nobody) Summary: windll, calldll don't work in 2.3c2 Initial Comment: calldll doesn't import in 2.3c2. windll doesn't either since it tries to import calldll (calldll.pyd). These libs are referenced in "Python Programming on Win32", Mark Hammond, Andy Robinson They work fine in 2.2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777943&group_id=5470 From noreply@sourceforge.net Sat Jul 26 13:20:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 26 Jul 2003 05:20:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-777867 ] test_ioctl fails Message-ID: Bugs item #777867, was opened at 2003-07-25 23:25 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 12:20 Message: Logged In: YES user_id=52562 Okay, I added "-v" to TESTOPTS in Makefile. test_ioctl test_ioctl (test.test_ioctl.IoctlTests) ... FAIL test_ioctl_mutate (test.test_ioctl.IoctlTests) ... FAIL ====================================================================== FAIL: test_ioctl (test.test_ioctl.IoctlTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py", line 22, in test_ioctl self.assertEquals(pgrp, struct.unpack("i", r)[0]) File "/home/zooko/playground/python/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 32261 != 28460 ====================================================================== FAIL: test_ioctl_mutate (test.test_ioctl.IoctlTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py", line 31, in test_ioctl_mutate self.assertEquals(pgrp, buf[0]) File "/home/zooko/playground/python/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 32261 != 28460 ---------------------------------------------------------------------- Ran 2 tests in 0.002s FAILED (failures=2) test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-25 23:52 Message: Logged In: YES user_id=6656 Oh dear. Could you hack 'make test' to pass -v to regrtest? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 23:44 Message: Logged In: YES user_id=52562 I cut and pasted the unit test code and ran it, and it passed. So I suppose it's a bug in how "make test" invokes the test_ioctl unit test? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-25 23:33 Message: Logged In: YES user_id=6656 Can you dig? I.e. more info than "test_ioctl fails"... try running the code that test_ioctl runs and see what that does ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 23:33 Message: Logged In: YES user_id=52562 The stuff I posted when I opened this bug report was all from running "make test". I have now discovered the "regrtest.py" file and am experimenting with it. -s doesn't seem to work for test_ioctl.py: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py -v -s ./Lib/test/test_ioctl.py ./Lib/test/test_ioctl test ./Lib/test/test_ioctl crashed -- exceptions.ValueError: Empty module name Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) ValueError: Empty module name 1 test failed: ./Lib/test/test_ioctl Traceback (most recent call last): File "./Lib/test/regrtest.py", line 1005, in ? main() File "./Lib/test/regrtest.py", line 332, in main os.unlink(filename) OSError: [Errno 2] No such file or directory: '/tmp/pynexttest' But running regrtest.py by itself runs a bunch of tests including test_ioctl, apparently successfully: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py ... test_ioctl ... 224 tests OK. 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale So I guess this is an "issue" in the make target rather than in the ioctl code itself... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 From noreply@sourceforge.net Sat Jul 26 14:15:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 26 Jul 2003 06:15:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 20:21 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 >Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 13:15 Message: Logged In: YES user_id=52562 Hm. I tried this an failed, then examining setup.py, I find that it is looking for "/usr/local/BerkeleyDB.x.y". So I moved my bsddb4.1 into there and tried again, and now I get the same sorts of errors that I got earlier. I will investigate them in the same ways I did last time and report back: gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I/usr/local/BerkeleyDB.4.1/include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb.c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create building 'dbm' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -DHAVE_BERKDB_H -DDB_DBM_HSEARCH -I/usr/local/BerkeleyDB.4.1/include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o 3.202 gcc -pthread -shared build/temp.linux-i686-2.3/dbmmodule.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -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: __db_ndbm_open ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-25 21:46 Message: Logged In: YES user_id=21627 I now see what is happening. setup.py indeed expects that no additional configuration is needed for /usr/local/lib. If you had configured Sleepycat BSDDB in its standard location (/usr/local/BerkeleyDBx.y), setup.py would have added a -R option. Closing it as "won't fix". ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 14:28 Message: Logged In: YES user_id=52562 Here's some more details about my system: * Debian unstable/testing * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * GNU Make 3.80 * AMD Athlon XP 1600+ ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 12:57 Message: Logged In: YES user_id=52562 I don't know if this is important, but I still can't build the bsddb3 module on my system without manually editing my /etc/ld.so.conf, and even after I do manually edit my /etc/ld.so.conf the tests seem to fail. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-23 12:59 Message: Logged In: YES user_id=52562 Could you tell me how to find out why distutils doesn't use the -R/-rpath option? Could it be that it assumes /usr/local/lib is already going to be in the ld path? By the way, having manually added /usr/local/lib to my /etc/ld.so.conf, it compiles with no errors, but make test yields the following: HACK pion:~/playground/python/python/dist/src$ grep -i -E --regex="bsddb|berk|db[^A-Za-z]" /tmp/zooko/logs/make.test.python test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd Is that right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 21:05 Message: Logged In: YES user_id=21627 Ok. Can you try to find out why distutils fails to use the -R/-rpath option? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 21:02 Message: Logged In: YES user_id=52562 Okay, I've tried these. -Wl,verbose tells me, as I expected: attempt to open /usr/local/stow/python-g/lib/libdb-4.1.so failed attempt to open /usr/local/stow/python-g/lib/libdb-4.1.a failed attempt to open /usr/local/lib/libdb-4.1.so succeeded -ldb-4.1 (/usr/local/lib/libdb-4.1.so) nm tells me, as expected, that db_create is present: MAIL pion:~$ nm /usr/local/lib/libdb-4.1.so | grep db_create 0001a554 T __bam_db_create 000783cc T __ham_db_create 000a5fe0 T __qam_db_create 000492c8 T db_create Adding /usr/local/lib to my /etc/ld.so.conf and running ldconfig *did* fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 20:41 Message: Logged In: YES user_id=21627 Please collect the following information: 1. Invoke the linker line with -Wl,--verbose (manually), to find out the path it uses for the -ldb-4.1 command line option. In particular, find out whether it uses a shared or static library (.so or .a) 2. Perform nm on that library|grep db_create The symbol really should be there; it is on all copies of -ldb-something that I can get hold of. If it is not in your copy, you somehow messed up the BerkeleyDB build. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 20:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 20:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Sat Jul 26 14:58:53 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 26 Jul 2003 06:58:53 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 20:21 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 13:58 Message: Logged In: YES user_id=52562 Okay, I installed bsddb in /usr/local/BerkeleyDB.4.1. It still didn't build. Investigating, I saw that it was linking against /usr/lib/libdb4.so which was provided by Debian. I uninstalled the debian package and tried again. Now it builds but fails unit tests. Just to be clear, I now have BerkeleyDB.4.1 in the standard location, and have no other libdb4's on my system, and it finishes "make" without any errors, but doesn't pass the test. I will continue to investigate. The result of the test is: test_bsddb test_bsddb skipped -- No module named _bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled ... 224 tests OK. 1 test failed: test_ioctl 30 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 3 skips unexpected on linux2: test_locale test_bz2 test_gdbm ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 13:15 Message: Logged In: YES user_id=52562 Hm. I tried this an failed, then examining setup.py, I find that it is looking for "/usr/local/BerkeleyDB.x.y". So I moved my bsddb4.1 into there and tried again, and now I get the same sorts of errors that I got earlier. I will investigate them in the same ways I did last time and report back: gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I/usr/local/BerkeleyDB.4.1/include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb.c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create building 'dbm' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -DHAVE_BERKDB_H -DDB_DBM_HSEARCH -I/usr/local/BerkeleyDB.4.1/include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o 3.202 gcc -pthread -shared build/temp.linux-i686-2.3/dbmmodule.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -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: __db_ndbm_open ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-25 21:46 Message: Logged In: YES user_id=21627 I now see what is happening. setup.py indeed expects that no additional configuration is needed for /usr/local/lib. If you had configured Sleepycat BSDDB in its standard location (/usr/local/BerkeleyDBx.y), setup.py would have added a -R option. Closing it as "won't fix". ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 14:28 Message: Logged In: YES user_id=52562 Here's some more details about my system: * Debian unstable/testing * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * GNU Make 3.80 * AMD Athlon XP 1600+ ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 12:57 Message: Logged In: YES user_id=52562 I don't know if this is important, but I still can't build the bsddb3 module on my system without manually editing my /etc/ld.so.conf, and even after I do manually edit my /etc/ld.so.conf the tests seem to fail. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-23 12:59 Message: Logged In: YES user_id=52562 Could you tell me how to find out why distutils doesn't use the -R/-rpath option? Could it be that it assumes /usr/local/lib is already going to be in the ld path? By the way, having manually added /usr/local/lib to my /etc/ld.so.conf, it compiles with no errors, but make test yields the following: HACK pion:~/playground/python/python/dist/src$ grep -i -E --regex="bsddb|berk|db[^A-Za-z]" /tmp/zooko/logs/make.test.python test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd Is that right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 21:05 Message: Logged In: YES user_id=21627 Ok. Can you try to find out why distutils fails to use the -R/-rpath option? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 21:02 Message: Logged In: YES user_id=52562 Okay, I've tried these. -Wl,verbose tells me, as I expected: attempt to open /usr/local/stow/python-g/lib/libdb-4.1.so failed attempt to open /usr/local/stow/python-g/lib/libdb-4.1.a failed attempt to open /usr/local/lib/libdb-4.1.so succeeded -ldb-4.1 (/usr/local/lib/libdb-4.1.so) nm tells me, as expected, that db_create is present: MAIL pion:~$ nm /usr/local/lib/libdb-4.1.so | grep db_create 0001a554 T __bam_db_create 000783cc T __ham_db_create 000a5fe0 T __qam_db_create 000492c8 T db_create Adding /usr/local/lib to my /etc/ld.so.conf and running ldconfig *did* fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 20:41 Message: Logged In: YES user_id=21627 Please collect the following information: 1. Invoke the linker line with -Wl,--verbose (manually), to find out the path it uses for the -ldb-4.1 command line option. In particular, find out whether it uses a shared or static library (.so or .a) 2. Perform nm on that library|grep db_create The symbol really should be there; it is on all copies of -ldb-something that I can get hold of. If it is not in your copy, you somehow messed up the BerkeleyDB build. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 20:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 20:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Sat Jul 26 15:08:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 26 Jul 2003 07:08:36 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 20:21 Message generated for change (Settings changed) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 >Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 14:08 Message: Logged In: YES user_id=52562 Oh, okay, test_bsddb3 skipped -- Use of the `bsddb' resource not enabled just means that regrtest doesn't run the bsddb tests by default. Also, I'm a bit confused about whether "test_bsddb3" is just for the legacy (separately installed bsddb v3) or if it also applies to the modern (bundled bsddb v4). ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 13:58 Message: Logged In: YES user_id=52562 Okay, I installed bsddb in /usr/local/BerkeleyDB.4.1. It still didn't build. Investigating, I saw that it was linking against /usr/lib/libdb4.so which was provided by Debian. I uninstalled the debian package and tried again. Now it builds but fails unit tests. Just to be clear, I now have BerkeleyDB.4.1 in the standard location, and have no other libdb4's on my system, and it finishes "make" without any errors, but doesn't pass the test. I will continue to investigate. The result of the test is: test_bsddb test_bsddb skipped -- No module named _bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled ... 224 tests OK. 1 test failed: test_ioctl 30 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 3 skips unexpected on linux2: test_locale test_bz2 test_gdbm ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 13:15 Message: Logged In: YES user_id=52562 Hm. I tried this an failed, then examining setup.py, I find that it is looking for "/usr/local/BerkeleyDB.x.y". So I moved my bsddb4.1 into there and tried again, and now I get the same sorts of errors that I got earlier. I will investigate them in the same ways I did last time and report back: gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I/usr/local/BerkeleyDB.4.1/include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb.c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create building 'dbm' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -DHAVE_BERKDB_H -DDB_DBM_HSEARCH -I/usr/local/BerkeleyDB.4.1/include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o 3.202 gcc -pthread -shared build/temp.linux-i686-2.3/dbmmodule.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -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: __db_ndbm_open ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-25 21:46 Message: Logged In: YES user_id=21627 I now see what is happening. setup.py indeed expects that no additional configuration is needed for /usr/local/lib. If you had configured Sleepycat BSDDB in its standard location (/usr/local/BerkeleyDBx.y), setup.py would have added a -R option. Closing it as "won't fix". ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 14:28 Message: Logged In: YES user_id=52562 Here's some more details about my system: * Debian unstable/testing * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * GNU Make 3.80 * AMD Athlon XP 1600+ ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 12:57 Message: Logged In: YES user_id=52562 I don't know if this is important, but I still can't build the bsddb3 module on my system without manually editing my /etc/ld.so.conf, and even after I do manually edit my /etc/ld.so.conf the tests seem to fail. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-23 12:59 Message: Logged In: YES user_id=52562 Could you tell me how to find out why distutils doesn't use the -R/-rpath option? Could it be that it assumes /usr/local/lib is already going to be in the ld path? By the way, having manually added /usr/local/lib to my /etc/ld.so.conf, it compiles with no errors, but make test yields the following: HACK pion:~/playground/python/python/dist/src$ grep -i -E --regex="bsddb|berk|db[^A-Za-z]" /tmp/zooko/logs/make.test.python test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd Is that right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 21:05 Message: Logged In: YES user_id=21627 Ok. Can you try to find out why distutils fails to use the -R/-rpath option? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 21:02 Message: Logged In: YES user_id=52562 Okay, I've tried these. -Wl,verbose tells me, as I expected: attempt to open /usr/local/stow/python-g/lib/libdb-4.1.so failed attempt to open /usr/local/stow/python-g/lib/libdb-4.1.a failed attempt to open /usr/local/lib/libdb-4.1.so succeeded -ldb-4.1 (/usr/local/lib/libdb-4.1.so) nm tells me, as expected, that db_create is present: MAIL pion:~$ nm /usr/local/lib/libdb-4.1.so | grep db_create 0001a554 T __bam_db_create 000783cc T __ham_db_create 000a5fe0 T __qam_db_create 000492c8 T db_create Adding /usr/local/lib to my /etc/ld.so.conf and running ldconfig *did* fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 20:41 Message: Logged In: YES user_id=21627 Please collect the following information: 1. Invoke the linker line with -Wl,--verbose (manually), to find out the path it uses for the -ldb-4.1 command line option. In particular, find out whether it uses a shared or static library (.so or .a) 2. Perform nm on that library|grep db_create The symbol really should be there; it is on all copies of -ldb-something that I can get hold of. If it is not in your copy, you somehow messed up the BerkeleyDB build. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 20:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 20:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Sat Jul 26 15:12:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 26 Jul 2003 07:12:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 16:21 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-26 10:12 Message: Logged In: YES user_id=12800 test_bsddb3 is the extensive test suite from the pybsddb project. It's a bit of a misnomer, but is definitely still appropriate for the bsddb module in Python 2.3. regrtest's "-u bsddb" enables it. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 10:08 Message: Logged In: YES user_id=52562 Oh, okay, test_bsddb3 skipped -- Use of the `bsddb' resource not enabled just means that regrtest doesn't run the bsddb tests by default. Also, I'm a bit confused about whether "test_bsddb3" is just for the legacy (separately installed bsddb v3) or if it also applies to the modern (bundled bsddb v4). ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 09:58 Message: Logged In: YES user_id=52562 Okay, I installed bsddb in /usr/local/BerkeleyDB.4.1. It still didn't build. Investigating, I saw that it was linking against /usr/lib/libdb4.so which was provided by Debian. I uninstalled the debian package and tried again. Now it builds but fails unit tests. Just to be clear, I now have BerkeleyDB.4.1 in the standard location, and have no other libdb4's on my system, and it finishes "make" without any errors, but doesn't pass the test. I will continue to investigate. The result of the test is: test_bsddb test_bsddb skipped -- No module named _bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled ... 224 tests OK. 1 test failed: test_ioctl 30 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 3 skips unexpected on linux2: test_locale test_bz2 test_gdbm ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 09:15 Message: Logged In: YES user_id=52562 Hm. I tried this an failed, then examining setup.py, I find that it is looking for "/usr/local/BerkeleyDB.x.y". So I moved my bsddb4.1 into there and tried again, and now I get the same sorts of errors that I got earlier. I will investigate them in the same ways I did last time and report back: gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I/usr/local/BerkeleyDB.4.1/include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb.c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create building 'dbm' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -DHAVE_BERKDB_H -DDB_DBM_HSEARCH -I/usr/local/BerkeleyDB.4.1/include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o 3.202 gcc -pthread -shared build/temp.linux-i686-2.3/dbmmodule.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -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: __db_ndbm_open ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-25 17:46 Message: Logged In: YES user_id=21627 I now see what is happening. setup.py indeed expects that no additional configuration is needed for /usr/local/lib. If you had configured Sleepycat BSDDB in its standard location (/usr/local/BerkeleyDBx.y), setup.py would have added a -R option. Closing it as "won't fix". ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 10:28 Message: Logged In: YES user_id=52562 Here's some more details about my system: * Debian unstable/testing * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * GNU Make 3.80 * AMD Athlon XP 1600+ ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 08:57 Message: Logged In: YES user_id=52562 I don't know if this is important, but I still can't build the bsddb3 module on my system without manually editing my /etc/ld.so.conf, and even after I do manually edit my /etc/ld.so.conf the tests seem to fail. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-23 08:59 Message: Logged In: YES user_id=52562 Could you tell me how to find out why distutils doesn't use the -R/-rpath option? Could it be that it assumes /usr/local/lib is already going to be in the ld path? By the way, having manually added /usr/local/lib to my /etc/ld.so.conf, it compiles with no errors, but make test yields the following: HACK pion:~/playground/python/python/dist/src$ grep -i -E --regex="bsddb|berk|db[^A-Za-z]" /tmp/zooko/logs/make.test.python test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd Is that right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 17:05 Message: Logged In: YES user_id=21627 Ok. Can you try to find out why distutils fails to use the -R/-rpath option? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 17:02 Message: Logged In: YES user_id=52562 Okay, I've tried these. -Wl,verbose tells me, as I expected: attempt to open /usr/local/stow/python-g/lib/libdb-4.1.so failed attempt to open /usr/local/stow/python-g/lib/libdb-4.1.a failed attempt to open /usr/local/lib/libdb-4.1.so succeeded -ldb-4.1 (/usr/local/lib/libdb-4.1.so) nm tells me, as expected, that db_create is present: MAIL pion:~$ nm /usr/local/lib/libdb-4.1.so | grep db_create 0001a554 T __bam_db_create 000783cc T __ham_db_create 000a5fe0 T __qam_db_create 000492c8 T db_create Adding /usr/local/lib to my /etc/ld.so.conf and running ldconfig *did* fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 16:41 Message: Logged In: YES user_id=21627 Please collect the following information: 1. Invoke the linker line with -Wl,--verbose (manually), to find out the path it uses for the -ldb-4.1 command line option. In particular, find out whether it uses a shared or static library (.so or .a) 2. Perform nm on that library|grep db_create The symbol really should be there; it is on all copies of -ldb-something that I can get hold of. If it is not in your copy, you somehow messed up the BerkeleyDB build. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 16:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 16:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Sat Jul 26 16:13:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 26 Jul 2003 08:13:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-775850 ] pybsddb build fails Message-ID: Bugs item #775850, was opened at 2003-07-22 20:21 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 Category: Build Group: Python 2.3 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: pybsddb build fails Initial Comment: This is either a bug in the build, or a bug in the build docs, or me being dumb. I read Modules/Setup and it said Berkeley DB 4.1 wasn't supported, but I later realized that this statement was out of date. Then I read somewhere -- I'm sorry I can't find this doc now that I'm writing this report -- that Berkeley DB 4.1 would be detected by the setup.py script after the interpreter was built during "make". So I installed Berkeley DB 4.1 and ran "make". It *did* detect that I had Berkeley DB installed, and attempted to build the wrapper, but failed like this: building '_bsddb' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb. c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 15:13 Message: Logged In: YES user_id=52562 Say, can anyone explain how to run *just* the bsddb unit test? I tried: HACK pion:~/playground/python/python/dist/src$ ./python -u ./Lib/test/regrtest.py -s ./Lib/test/test_bsddb.py ./Lib/test/test_bsddb test ./Lib/test/test_bsddb crashed -- exceptions.ValueError: Empty module name 1 test failed: ./Lib/test/test_bsddb Traceback (most recent call last): File "./Lib/test/regrtest.py", line 1005, in ? main() File "./Lib/test/regrtest.py", line 332, in main os.unlink(filename) OSError: [Errno 2] No such file or directory: '/tmp/pynexttest' ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-26 14:12 Message: Logged In: YES user_id=12800 test_bsddb3 is the extensive test suite from the pybsddb project. It's a bit of a misnomer, but is definitely still appropriate for the bsddb module in Python 2.3. regrtest's "-u bsddb" enables it. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 14:08 Message: Logged In: YES user_id=52562 Oh, okay, test_bsddb3 skipped -- Use of the `bsddb' resource not enabled just means that regrtest doesn't run the bsddb tests by default. Also, I'm a bit confused about whether "test_bsddb3" is just for the legacy (separately installed bsddb v3) or if it also applies to the modern (bundled bsddb v4). ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 13:58 Message: Logged In: YES user_id=52562 Okay, I installed bsddb in /usr/local/BerkeleyDB.4.1. It still didn't build. Investigating, I saw that it was linking against /usr/lib/libdb4.so which was provided by Debian. I uninstalled the debian package and tried again. Now it builds but fails unit tests. Just to be clear, I now have BerkeleyDB.4.1 in the standard location, and have no other libdb4's on my system, and it finishes "make" without any errors, but doesn't pass the test. I will continue to investigate. The result of the test is: test_bsddb test_bsddb skipped -- No module named _bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled ... 224 tests OK. 1 test failed: test_ioctl 30 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 3 skips unexpected on linux2: test_locale test_bz2 test_gdbm ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 13:15 Message: Logged In: YES user_id=52562 Hm. I tried this an failed, then examining setup.py, I find that it is looking for "/usr/local/BerkeleyDB.x.y". So I moved my bsddb4.1 into there and tried again, and now I get the same sorts of errors that I got earlier. I will investigate them in the same ways I did last time and report back: gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -I/usr/local/BerkeleyDB.4.1/include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/_bsddb.c -o build/temp.linux-i686-2.3/_bsddb.o gcc -pthread -shared build/temp.linux-i686-2.3/_bsddb.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -o build/lib.linux-i686-2.3/_bsddb.so *** WARNING: renaming "_bsddb" since importing it failed: build/lib.linux-i686-2.3/_bsddb.so: undefined symbol: db_create building 'dbm' extension gcc -pthread -DNDEBUG -g -fPIC -fno-strict-aliasing -DHAVE_BERKDB_H -DDB_DBM_HSEARCH -I/usr/local/BerkeleyDB.4.1/include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I. -I/home/zooko/playground/python/python/dist/src/./Include -I/usr/local/stow/python-g/include -I/usr/local/include -I/home/zooko/playground/python/python/dist/src/Include -I/home/zooko/playground/python/python/dist/src -c /home/zooko/playground/python/python/dist/src/Modules/dbmmodule.c -o build/temp.linux-i686-2.3/dbmmodule.o 3.202 gcc -pthread -shared build/temp.linux-i686-2.3/dbmmodule.o -L/usr/local/stow/python-g/lib -L/usr/local/lib -ldb-4.1 -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: __db_ndbm_open ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-25 21:46 Message: Logged In: YES user_id=21627 I now see what is happening. setup.py indeed expects that no additional configuration is needed for /usr/local/lib. If you had configured Sleepycat BSDDB in its standard location (/usr/local/BerkeleyDBx.y), setup.py would have added a -R option. Closing it as "won't fix". ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 14:28 Message: Logged In: YES user_id=52562 Here's some more details about my system: * Debian unstable/testing * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * GNU Make 3.80 * AMD Athlon XP 1600+ ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 12:57 Message: Logged In: YES user_id=52562 I don't know if this is important, but I still can't build the bsddb3 module on my system without manually editing my /etc/ld.so.conf, and even after I do manually edit my /etc/ld.so.conf the tests seem to fail. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-23 12:59 Message: Logged In: YES user_id=52562 Could you tell me how to find out why distutils doesn't use the -R/-rpath option? Could it be that it assumes /usr/local/lib is already going to be in the ld path? By the way, having manually added /usr/local/lib to my /etc/ld.so.conf, it compiles with no errors, but make test yields the following: HACK pion:~/playground/python/python/dist/src$ grep -i -E --regex="bsddb|berk|db[^A-Za-z]" /tmp/zooko/logs/make.test.python test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_bsddb test_bsddb185 test_bsddb185 skipped -- No module named bsddb185 test_bsddb3 test_bsddb3 skipped -- Use of the `bsddb' resource not enabled test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd Is that right? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 21:05 Message: Logged In: YES user_id=21627 Ok. Can you try to find out why distutils fails to use the -R/-rpath option? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 21:02 Message: Logged In: YES user_id=52562 Okay, I've tried these. -Wl,verbose tells me, as I expected: attempt to open /usr/local/stow/python-g/lib/libdb-4.1.so failed attempt to open /usr/local/stow/python-g/lib/libdb-4.1.a failed attempt to open /usr/local/lib/libdb-4.1.so succeeded -ldb-4.1 (/usr/local/lib/libdb-4.1.so) nm tells me, as expected, that db_create is present: MAIL pion:~$ nm /usr/local/lib/libdb-4.1.so | grep db_create 0001a554 T __bam_db_create 000783cc T __ham_db_create 000a5fe0 T __qam_db_create 000492c8 T db_create Adding /usr/local/lib to my /etc/ld.so.conf and running ldconfig *did* fix it. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 20:41 Message: Logged In: YES user_id=21627 Please collect the following information: 1. Invoke the linker line with -Wl,--verbose (manually), to find out the path it uses for the -ldb-4.1 command line option. In particular, find out whether it uses a shared or static library (.so or .a) 2. Perform nm on that library|grep db_create The symbol really should be there; it is on all copies of -ldb-something that I can get hold of. If it is not in your copy, you somehow messed up the BerkeleyDB build. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-22 20:40 Message: Logged In: YES user_id=12800 I'm betting that _bsddb couldn't be imported because the runtime location of the library couldn't be found. I thought at one time we were adding the proper -R flag to get that compiled in, but it doesn't look like that's getting added for you. You could try adding /usr/local/BerkeleyDB.4.1/lib to your /etc/ld.so.conf file and run ldconfig. If that "fixes" it, then we should try to figure out why setup.py isn't adding -R/usr/local/BerkeleyDB.4.1/lib to the link line. You can also try moving build/lib.linux-i686-2.3/_bsddb.so.failed back to _bsddb.so and doing an "import _bsddb". You'll get more information about why the import failed. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-22 20:28 Message: Logged In: YES user_id=52562 I should mention that I installed the current bsddb4.1 from sleepycat: db-4.1.25.tar.gz, and I just cvs up'ed Python a few minutes ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775850&group_id=5470 From noreply@sourceforge.net Sat Jul 26 16:59:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 26 Jul 2003 08:59:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-778119 ] Shared Python Library installed without link Message-ID: Bugs item #778119, was opened at 2003-07-26 17: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=778119&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Achim Gaedke (achimgaedke) Assigned to: Nobody/Anonymous (nobody) Summary: Shared Python Library installed without link Initial Comment: Hi! I've read the Changes of python2.3c2 and found good news of a shared python library. It is installed at: /usr/local/lib/libpython2.3.so.1.0 For compatibility most installer link such libraries with full version number to a simple name: libpython2.3.so . Maybe you can add such a feature to the Makefile. My system: Redhat-8.0 with all available patches applied. Python Version: Python2.3c2 source distribution ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778119&group_id=5470 From noreply@sourceforge.net Sun Jul 27 01:46:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 26 Jul 2003 17:46:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-778274 ] Building an extension with Python 2.3c2 Message-ID: Bugs item #778274, was opened at 2003-07-27 00: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=778274&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Selim Tuvi (stuvi) Assigned to: Nobody/Anonymous (nobody) Summary: Building an extension with Python 2.3c2 Initial Comment: Hi I am testing Python 2.3c2 with our software which has an extension module component and I am getting the following error when I try to build it. error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. I am using Visual Studio .Net 2002 under Windows XP. SWIG version is 1.3.17. I used to be able to build this with ActiveState Python 2.2.2 build 224. Does this mean that we need a version of Python 2.3 thta is built with Visual Studio .Net? Thanks -Selim ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778274&group_id=5470 From noreply@sourceforge.net Sun Jul 27 05:58:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 26 Jul 2003 21:58:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-778274 ] Building an extension with Python 2.3c2 Message-ID: Bugs item #778274, was opened at 2003-07-26 20:46 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778274&group_id=5470 >Category: Windows Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Selim Tuvi (stuvi) >Assigned to: Tim Peters (tim_one) Summary: Building an extension with Python 2.3c2 Initial Comment: Hi I am testing Python 2.3c2 with our software which has an extension module component and I am getting the following error when I try to build it. error: Python was built with version 6 of Visual Studio, and extensions need to be built with the same version of the compiler, but it isn't installed. I am using Visual Studio .Net 2002 under Windows XP. SWIG version is 1.3.17. I used to be able to build this with ActiveState Python 2.2.2 build 224. Does this mean that we need a version of Python 2.3 thta is built with Visual Studio .Net? Thanks -Selim ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-27 00:58 Message: Logged In: YES user_id=31435 The C runtimes are distinct between VC6 and VC7, so (for example) doing things like passing a FILE* created in one to a stdio function in the other can cause anything from subtle memory corruption to an immediate crash. You'll have to build Python with VC7 too (others have done so -- it works), or build your extensions with VC6. Another possibility is to fiddle the source code to suppress the error message you're getting now, and take your chances with dual-CRT insanities. PythonLabs doesn't have the resource to build under VC7 too (we don't even have an optimizing VC7 compiler). If there's interest in getting one, interested parties will have to do the work themselves, or fund it. Perhaps ActiveState has plans in this direction already (I really don't know). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778274&group_id=5470 From noreply@sourceforge.net Sun Jul 27 06:01:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 26 Jul 2003 22:01:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-777848 ] CGIHTTPServer and urls Message-ID: Bugs item #777848, was opened at 2003-07-25 17:41 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777848&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent delft (vincent_delft) Assigned to: Raymond Hettinger (rhettinger) Summary: CGIHTTPServer and urls Initial Comment: If you have 2 differents CGI. On the both you ask to print the content of cgi.FieldStorage. You will see that URL paramters (after ? in the url) remains. For our example : 1) http://localhost:8080/cgi-bin/script1.py?action=test Will display the parameter name 'action' and his value 'test' BUT, now you ask the second url 2) http://localhost:8080/cgi-bin/script2.py you still see the previous parameter 'action' with the previous value 'test' I've resolve the problem by removing a test in the CGIHTTPServer.py script. line +- 149 - if query: - env['QUERY_STRING'] = query + env['QUERY_STRING'] = query Indeed, the os.environ.update(env) does not modify 'QUERY_STRING' if you are not givin a new value. But in this case empty is a new value, and must be take in account. I don't know if my resolution is the best one. But now it works like it should be. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-27 00:01 Message: Logged In: YES user_id=80475 Will take a closer look at this one. Initially, I was concerned that some CGI scripts check for the existence rather than the nullity of the QUERY_STRING key. Now, I'm perplexed by why this isn't being handled by the for-loop (a few lines down from the part you patched) which "provides empty values to override previously set values". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777848&group_id=5470 From noreply@sourceforge.net Sun Jul 27 06:12:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 26 Jul 2003 22:12:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-777659 ] Uninitialized variable used in Tools/faqwiz/faqwiz.py Message-ID: Bugs item #777659, was opened at 2003-07-25 11:39 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777659&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Smith (johnjsmith) >Assigned to: Guido van Rossum (gvanrossum) Summary: Uninitialized variable used in Tools/faqwiz/faqwiz.py Initial Comment: Python: 2.3rc2 The uninitialized variable tfn is used in Tools/faqwiz/faqwiz.py (lines 811, 833). ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-27 00:12 Message: Logged In: YES user_id=80475 Guido, these lines were from your patch in 2002. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777659&group_id=5470 From noreply@sourceforge.net Sun Jul 27 06:16:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 26 Jul 2003 22:16:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-777943 ] windll, calldll don't work in 2.3c2 Message-ID: Bugs item #777943, was opened at 2003-07-26 01:16 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777943&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: james althoff (jamesalthoff) Assigned to: Nobody/Anonymous (nobody) Summary: windll, calldll don't work in 2.3c2 Initial Comment: calldll doesn't import in 2.3c2. windll doesn't either since it tries to import calldll (calldll.pyd). These libs are referenced in "Python Programming on Win32", Mark Hammond, Andy Robinson They work fine in 2.2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777943&group_id=5470 From noreply@sourceforge.net Sun Jul 27 10:32:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 02:32:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-778400 ] IDLE hangs when selecting "Edit with IDLE" from explorer Message-ID: Bugs item #778400, was opened at 2003-07-27 12: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=778400&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE hangs when selecting "Edit with IDLE" from explorer Initial Comment: IDLE editor window hangs when right clicking a file and selecting "Edit with IDLE" Steps to reproduce: o Open IDLE o Open explorer o Right click on a .py file o Choose "Edit with IDLE" A new IDLE edit window opens but it is not responding. The original (shell) IDLE window works fine. If you do the above without opening an IDLE shell it works fine. My system is win2k on IBM T30 (LapTop). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778400&group_id=5470 From noreply@sourceforge.net Sun Jul 27 10:33:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 02:33:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-772787 ] right button context 'edit with idle' Message-ID: Bugs item #772787, was opened at 2003-07-17 07:36 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 4 Submitted By: nestor (nestor5) Assigned to: Nobody/Anonymous (nobody) Summary: right button context 'edit with idle' Initial Comment: after installing Python 2.3b2 under windows, the right mouse button context option in windows explorer 'edit with idle' on *.py files ceased to work on two mashines (I upgraded from python b1 to b2). One was Windows 2000 and one was Windows XP. Installation is default C:\python23 installation. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-27 12:33 Message: Logged In: YES user_id=358087 It's not fixed for me in rc2. As Tim request see bug 778400. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-25 18:44 Message: Logged In: YES user_id=31435 The original bug is fixed, but the other bug reported by tebeka in a comment has not been fixed. It would help if tebeka opened a new bug report for that, so it's clearly identifed in the system as a distinct bug. ---------------------------------------------------------------------- Comment By: nestor (nestor5) Date: 2003-07-25 18:35 Message: Logged In: YES user_id=793384 these seem to be fixed in Python 2.3c2. Can you confirm this tebeka? So we can close this bug? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 18:36 Message: Logged In: YES user_id=31435 On Win2K I can't reproduce tebeka's problem with the instructions as given. But I get a frozen window if I repeat the last two steps. o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" o Right click on another .py file o Choose "Edit with IDLE" ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 10:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 10:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 From noreply@sourceforge.net Sun Jul 27 12:07:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 04:07:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-778119 ] Shared Python Library installed without link Message-ID: Bugs item #778119, was opened at 2003-07-26 17:59 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778119&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Achim Gaedke (achimgaedke) Assigned to: Nobody/Anonymous (nobody) Summary: Shared Python Library installed without link Initial Comment: Hi! I've read the Changes of python2.3c2 and found good news of a shared python library. It is installed at: /usr/local/lib/libpython2.3.so.1.0 For compatibility most installer link such libraries with full version number to a simple name: libpython2.3.so . Maybe you can add such a feature to the Makefile. My system: Redhat-8.0 with all available patches applied. Python Version: Python2.3c2 source distribution ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-27 13:07 Message: Logged In: YES user_id=21627 Does the link appear if you run ldconfig? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778119&group_id=5470 From noreply@sourceforge.net Sun Jul 27 12:09:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 04:09:20 -0700 Subject: [Python-bugs-list] [ python-Bugs-777943 ] windll, calldll don't work in 2.3c2 Message-ID: Bugs item #777943, was opened at 2003-07-26 08:16 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777943&group_id=5470 Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Invalid Priority: 6 Submitted By: james althoff (jamesalthoff) Assigned to: Nobody/Anonymous (nobody) Summary: windll, calldll don't work in 2.3c2 Initial Comment: calldll doesn't import in 2.3c2. windll doesn't either since it tries to import calldll (calldll.pyd). These libs are referenced in "Python Programming on Win32", Mark Hammond, Andy Robinson They work fine in 2.2.3. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-27 13:09 Message: Logged In: YES user_id=21627 This is not a bug. You need to recompile extension modules for each Python version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777943&group_id=5470 From noreply@sourceforge.net Sun Jul 27 12:10:40 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 04:10:40 -0700 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-26 02:22 Message generated for change (Comment added) made by loewis 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: Nobody/Anonymous (nobody) 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-07-27 13: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@sourceforge.net Sun Jul 27 12:53:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 04:53:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-777848 ] CGIHTTPServer and urls Message-ID: Bugs item #777848, was opened at 2003-07-26 00:41 Message generated for change (Comment added) made by vincent_delft You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777848&group_id=5470 Category: Python Library Group: Python 2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent delft (vincent_delft) Assigned to: Raymond Hettinger (rhettinger) Summary: CGIHTTPServer and urls Initial Comment: If you have 2 differents CGI. On the both you ask to print the content of cgi.FieldStorage. You will see that URL paramters (after ? in the url) remains. For our example : 1) http://localhost:8080/cgi-bin/script1.py?action=test Will display the parameter name 'action' and his value 'test' BUT, now you ask the second url 2) http://localhost:8080/cgi-bin/script2.py you still see the previous parameter 'action' with the previous value 'test' I've resolve the problem by removing a test in the CGIHTTPServer.py script. line +- 149 - if query: - env['QUERY_STRING'] = query + env['QUERY_STRING'] = query Indeed, the os.environ.update(env) does not modify 'QUERY_STRING' if you are not givin a new value. But in this case empty is a new value, and must be take in account. I don't know if my resolution is the best one. But now it works like it should be. ---------------------------------------------------------------------- >Comment By: vincent delft (vincent_delft) Date: 2003-07-27 13:53 Message: Logged In: YES user_id=106404 I don't see the for-loop ? If you are talking about the following : if not self.have_fork: # Since we're setting the env in the parent, provide empty # values to override previously set values for k in ('QUERY_STRING', 'REMOTE_HOST', 'CONTENT_LENGTH', 'HTTP_USER_AGENT', 'HTTP_COOKIE'): env.setdefault(k, "") It's normal that he not used because I'm on Linux machine. So, I have fork capabilities. Honestly I don't understand this loop. Indeed, You set to default values that was defined just before. In general we set the default before. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-27 07:01 Message: Logged In: YES user_id=80475 Will take a closer look at this one. Initially, I was concerned that some CGI scripts check for the existence rather than the nullity of the QUERY_STRING key. Now, I'm perplexed by why this isn't being handled by the for-loop (a few lines down from the part you patched) which "provides empty values to override previously set values". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777848&group_id=5470 From noreply@sourceforge.net Sun Jul 27 13:20:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 05:20:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-778119 ] Shared Python Library installed without link Message-ID: Bugs item #778119, was opened at 2003-07-26 17:59 Message generated for change (Comment added) made by achimgaedke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778119&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Achim Gaedke (achimgaedke) Assigned to: Nobody/Anonymous (nobody) Summary: Shared Python Library installed without link Initial Comment: Hi! I've read the Changes of python2.3c2 and found good news of a shared python library. It is installed at: /usr/local/lib/libpython2.3.so.1.0 For compatibility most installer link such libraries with full version number to a simple name: libpython2.3.so . Maybe you can add such a feature to the Makefile. My system: Redhat-8.0 with all available patches applied. Python Version: Python2.3c2 source distribution ---------------------------------------------------------------------- >Comment By: Achim Gaedke (achimgaedke) Date: 2003-07-27 14:20 Message: Logged In: YES user_id=246687 No. To be more exact: I usually install new programs to /opt/prgname-version, so the example was a little bit unusual for me. As you suggested I executed as root: ldconfig -n /opt/Python-2.3c2/lib This should update the link, but not the ldso.cache (as stated in the man-page). But it does not work. Maybe, the SONAME of this library is too detailed: objdump -p /opt/Python-2.3c2/lib/libpython2.3.so.1.0|grep SONAME SONAME libpython2.3.so.1.0 Ok, I've changed soname (-Wl,-soname=libpython2.3.so) and now the link appears! ldconfig -vn /opt/Python-2.3c2/lib /opt/Python-2.3c2/lib: libpython2.3.so -> libpython2.3.so.1.0 (changed) One (hard)link is set in the build-directory. But it is not copied to the install directory. My suggestion is to change the Makefile: 1) -Wl,-soname should give the short name 2) Set a link or run ldconfig -n $(LIBDIR) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-27 13:07 Message: Logged In: YES user_id=21627 Does the link appear if you run ldconfig? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778119&group_id=5470 From noreply@sourceforge.net Sun Jul 27 17:22:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 09:22:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-775964 ] fix test_grp failing on RedHat 6.2 Message-ID: Bugs item #775964, was opened at 2003-07-22 19:07 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Barry A. Warsaw (bwarsaw) Summary: fix test_grp failing on RedHat 6.2 Initial Comment: I didn't really think this should go into 2.3, but I'll let you make the decision. This patch fixes the test_grp failure on RedHat 6.2/Alpha (asmodean) in the snake-farm. I thought it was specific to RH 6.2, apparently it's not. If you add a + as the last line in /etc/group the test will fail on RH 9 too. Walter Doerwald may know more about how best to fix this. I'm not certain if it's really a problem in the extension module or the test. If you want to fix the test, the patch is included here: def check_value(self, value): # check that a grp tuple has the entries and # attributes promised by the docs + if value == ('+', None, 0, []): + # some libc's return the last line of + + return ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-27 12:22 Message: Logged In: YES user_id=12800 Remind me what + on a line means in /etc/group. "man group" on RH9 gives no clue. I'm still nervous about it, can we defer until 2.3.1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 From noreply@sourceforge.net Sun Jul 27 17:43:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 09:43:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-772787 ] right button context 'edit with idle' Message-ID: Bugs item #772787, was opened at 2003-07-17 00:36 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 Category: Installation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: nestor (nestor5) Assigned to: Nobody/Anonymous (nobody) Summary: right button context 'edit with idle' Initial Comment: after installing Python 2.3b2 under windows, the right mouse button context option in windows explorer 'edit with idle' on *.py files ceased to work on two mashines (I upgraded from python b1 to b2). One was Windows 2000 and one was Windows XP. Installation is default C:\python23 installation. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-27 12:43 Message: Logged In: YES user_id=31435 The original bug was fixed (the Windows installer needed to change the path to IDLE stored in the menu shortcut), so closing this. tebeka opened bug 778400 for the other issue (which isn't related to the original issue, apart from that they both use IDLE). ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-27 05:33 Message: Logged In: YES user_id=358087 It's not fixed for me in rc2. As Tim request see bug 778400. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-25 11:44 Message: Logged In: YES user_id=31435 The original bug is fixed, but the other bug reported by tebeka in a comment has not been fixed. It would help if tebeka opened a new bug report for that, so it's clearly identifed in the system as a distinct bug. ---------------------------------------------------------------------- Comment By: nestor (nestor5) Date: 2003-07-25 11:35 Message: Logged In: YES user_id=793384 these seem to be fixed in Python 2.3c2. Can you confirm this tebeka? So we can close this bug? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-21 11:36 Message: Logged In: YES user_id=31435 On Win2K I can't reproduce tebeka's problem with the instructions as given. But I get a frozen window if I repeat the last two steps. o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" o Right click on another .py file o Choose "Edit with IDLE" ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 03:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-21 03:34 Message: Logged In: YES user_id=358087 In c1 on win2k it works. However if there is an IDLE window already open then the new editor window is frozen. To repeat: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" The new IDLE editor window is frozen. Miki ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=772787&group_id=5470 From noreply@sourceforge.net Sun Jul 27 17:53:32 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 09:53:32 -0700 Subject: [Python-bugs-list] [ python-Bugs-778400 ] IDLE hangs when selecting "Edit with IDLE" from explorer Message-ID: Bugs item #778400, was opened at 2003-07-27 05:32 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778400&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when selecting "Edit with IDLE" from explorer Initial Comment: IDLE editor window hangs when right clicking a file and selecting "Edit with IDLE" Steps to reproduce: o Open IDLE o Open explorer o Right click on a .py file o Choose "Edit with IDLE" A new IDLE edit window opens but it is not responding. The original (shell) IDLE window works fine. If you do the above without opening an IDLE shell it works fine. My system is win2k on IBM T30 (LapTop). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-27 12:53 Message: Logged In: YES user_id=31435 Assigned to Kurt. On Win2K the steps above don't create a problem for me, but I get a frozen window if I repeat the last two steps. The whole failing sequence for me on a Win2K desktop box: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" o Right click on another .py file o Choose "Edit with IDLE" On Win98SE, the first "Edit with IDLE" works fine. The second "Edit with IDLE" opens a new shell window but not a window for the selected .py file. Third and subsequent "Edit with IDLE" steps have no visible effect (neither a new shell nor a new edit window open). Something is left in a hosed state then: if I close all the open IDLE windows, and try "Edit with IDLE" again, nothing visible happens. The Win98SE task manager (Ctrl+Alt+Del) doesn't show any Python processes running at that point, and neither does WinTop. It's still possible to start another IDLE, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778400&group_id=5470 From noreply@sourceforge.net Sun Jul 27 19:52:17 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 11:52:17 -0700 Subject: [Python-bugs-list] [ python-Bugs-778558 ] Malformed HTML in the FAQ Wizard Message-ID: Bugs item #778558, was opened at 2003-07-27 18:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778558&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Smith (johnjsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Malformed HTML in the FAQ Wizard Initial Comment: Python: 2.3c2 The last line of Tools/faqwiz/faqw.py prints timing statistics *after* the end of the output as indicated by the . This line would be better kept commented out in the distribution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778558&group_id=5470 From noreply@sourceforge.net Sun Jul 27 20:16:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 12:16:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-746895 ] socket.sendto(SOCK_DGRAM) very slow on OSX! Message-ID: Bugs item #746895, was opened at 2003-06-01 02:21 Message generated for change (Comment added) made by mkangas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746895&group_id=5470 Category: Python Library Group: Platform-specific >Status: Closed Resolution: None Priority: 5 Submitted By: Matt Kangas (mkangas) Assigned to: Nobody/Anonymous (nobody) Summary: socket.sendto(SOCK_DGRAM) very slow on OSX! Initial Comment: I'm trying to send UDP packets using socket.sendto(). With Python 2.2 on Linux, this works like a champ. On Mac OS X, something's terribly wrong. Time to send 100 UDP packets using test code + Python 2.2.1: - Linux 2.4.18 (RedHat 8): 0.009 sec - MacOS X 10.2.6: > 1 sec, sometimes > 2 sec. I've tried the following Python builds on OS X, all with the same results: - Stock 2.2 build that comes with OS X 10.2 - 2.2.1 provided by Fink - built-from-scratch 2.2.3: "./configure; make" provided are sample programs in Python and C. ktrace/kdump seem to indicate that both programs make the same sequence of syscalls. the C program runs blazingly fast on OS X, while the Python one seems to stall on every call to socket.sendto(). why does socket.sendto() perform so poorly on OS X? ----------------- python sample ---------------- # # UDP socket test: how fast can we write? # (5/2003 kangas) # # time to run with python 2.2.1: # - Linux 2.4.18: 0.009 sec # - Mac OS x 10.2.6: 1.272 sec (!!!) import socket, time, sys PORT = 9999 DEST_ADDR = ("192.168.1.60", PORT) def run(): maxcount = 100 data = "pingme pingme pingme pingme pingme..." dest = DEST_ADDR print "opening socket" s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) print "Sending %i packets" % maxcount t0 = time.time() for i in xrange(0, maxcount): s.sendto(data, dest) t1 = time.time() - t0 print "%0.4f secs elapsed" % t1 s.close() if __name__=="__main__": run() ----------------- C sample ---------------- /* * UDP socket test: how fast can we write? * (5/2003 kangas) * * Tested on Mac OS X 10.2.6 and Linux 2.4 */ #include #include #include #include static const int MAXCOUNT = 100; static const char DATA[] = "pingme pingme pingme pingme pingme..."; int main(void) { int s, i, err; struct sockaddr_in serverAddr; bzero(&serverAddr, sizeof(serverAddr)); serverAddr.sin_family = AF_INET; serverAddr.sin_port = htons(9999); inet_pton(AF_INET, "192.168.1.60", &serverAddr.sin_addr); printf("opening socket\n"); if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { perror("socket"); exit(1); } printf("sending %i packets\n", MAXCOUNT); for (i=0; iComment By: Matt Kangas (mkangas) Date: 2003-07-27 15:16 Message: Logged In: YES user_id=234623 Confirmed that it is fixed in 2.3c2. My python testcase now runs in 0.096 secs. Would anyone happen to know what exactly changed for gethostbyname() calls on OSX btw. 2.2 and 2.3? I ask because PHP 4.3.2 seems to suffer from the very same problem! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-06-16 09:12 Message: Logged In: YES user_id=45365 Hmm. It looks like something that is fixed in 2.3. When running the example with Apple's /usr/bin/python 2.2 I get "0.6942 secs elapsed". When I run it with 2.3b2 from CVS I get "0.0069 secs elapsed". Could this be an effect of the gethostbyname() mods that were done for numeric addresses? Yes, it seems it could be. 1000 calls to gethostbyname("192.168.1.60") cost 7.4 seconds in Python 2.2, while 2.3b2 needs only 0.02 seconds. I don't know whether these fixes can be backported to 2.2, though (nor even exactly what they are:-) ---------------------------------------------------------------------- Comment By: Matt Kangas (mkangas) Date: 2003-06-14 18:21 Message: Logged In: YES user_id=234623 "otool -L" (similar to Linux's ldd) shows the following for my freshly-built Python 2.2.3 interpreter: drinkycrow:Python-2.2.3$ otool -L python.exe python.exe: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 63.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 14.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 462.0.0) drinkycrow:Python-2.2.3$ ./python.exe Python 2.2.3 (#2, Jun 14 2003, 17:58:35) [GCC 3.1 20020420 (prerelease)] on darwin -------------------------------------- I added the following CFLAGS line to my makefile: CFLAGS = -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -framework System -framework CoreServices -framework Foundation These are, AFAIK, all of the relevant options used when building _socket.so and python.exe. (See attached "build_notes.txt" for full details) ------------------------------------------ How does the C test-case perform now? Slower than before, but still an order of magnitude faster than the Python code! drinkycrow:udp_test_py$ make clean; make rm socktest gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -framework System-framework CoreServices -framework Foundation socktest.c -o socktest socktest.c: In function `main': socktest.c:21: warning: implicit declaration of function `bzero' socktest.c:25: warning: implicit declaration of function `inet_pton' socktest.c:30: warning: implicit declaration of function `exit' socktest.c:35: warning: implicit declaration of function `strlen' socktest.c:46: warning: implicit declaration of function `close' drinkycrow:udp_test_py$ time ./socktest opening socket sending 100 packets .................................................................................................... closing... done! real 0m0.164s user 0m0.030s sys 0m0.040s drinkycrow:udp_test_py$ otool -L socktest socktest: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 63.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 14.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 462.0.0) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 02:55 Message: Logged In: YES user_id=21627 Can you try to link your C program with the same libraries that python is linked with, and compile it with the same command line options that socketmodule is compiled with? My first guess is that enabling pthreads may have an effect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746895&group_id=5470 From noreply@sourceforge.net Sun Jul 27 22:34:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 14:34:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-746895 ] socket.sendto(SOCK_DGRAM) very slow on OSX! Message-ID: Bugs item #746895, was opened at 2003-06-01 08:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746895&group_id=5470 Category: Python Library Group: Platform-specific Status: Closed Resolution: None Priority: 5 Submitted By: Matt Kangas (mkangas) Assigned to: Nobody/Anonymous (nobody) Summary: socket.sendto(SOCK_DGRAM) very slow on OSX! Initial Comment: I'm trying to send UDP packets using socket.sendto(). With Python 2.2 on Linux, this works like a champ. On Mac OS X, something's terribly wrong. Time to send 100 UDP packets using test code + Python 2.2.1: - Linux 2.4.18 (RedHat 8): 0.009 sec - MacOS X 10.2.6: > 1 sec, sometimes > 2 sec. I've tried the following Python builds on OS X, all with the same results: - Stock 2.2 build that comes with OS X 10.2 - 2.2.1 provided by Fink - built-from-scratch 2.2.3: "./configure; make" provided are sample programs in Python and C. ktrace/kdump seem to indicate that both programs make the same sequence of syscalls. the C program runs blazingly fast on OS X, while the Python one seems to stall on every call to socket.sendto(). why does socket.sendto() perform so poorly on OS X? ----------------- python sample ---------------- # # UDP socket test: how fast can we write? # (5/2003 kangas) # # time to run with python 2.2.1: # - Linux 2.4.18: 0.009 sec # - Mac OS x 10.2.6: 1.272 sec (!!!) import socket, time, sys PORT = 9999 DEST_ADDR = ("192.168.1.60", PORT) def run(): maxcount = 100 data = "pingme pingme pingme pingme pingme..." dest = DEST_ADDR print "opening socket" s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) print "Sending %i packets" % maxcount t0 = time.time() for i in xrange(0, maxcount): s.sendto(data, dest) t1 = time.time() - t0 print "%0.4f secs elapsed" % t1 s.close() if __name__=="__main__": run() ----------------- C sample ---------------- /* * UDP socket test: how fast can we write? * (5/2003 kangas) * * Tested on Mac OS X 10.2.6 and Linux 2.4 */ #include #include #include #include static const int MAXCOUNT = 100; static const char DATA[] = "pingme pingme pingme pingme pingme..."; int main(void) { int s, i, err; struct sockaddr_in serverAddr; bzero(&serverAddr, sizeof(serverAddr)); serverAddr.sin_family = AF_INET; serverAddr.sin_port = htons(9999); inet_pton(AF_INET, "192.168.1.60", &serverAddr.sin_addr); printf("opening socket\n"); if ((s = socket(AF_INET, SOCK_DGRAM, 0)) < 0) { perror("socket"); exit(1); } printf("sending %i packets\n", MAXCOUNT); for (i=0; iComment By: Martin v. Löwis (loewis) Date: 2003-07-27 23:34 Message: Logged In: YES user_id=21627 In 2.3, Python now uses the C library's getaddrinfo, instead of an emulated one that uses gethostbyname. Interestingly enough, this change has been attributed to a slowdown in 2.3 over 2.2 also. ---------------------------------------------------------------------- Comment By: Matt Kangas (mkangas) Date: 2003-07-27 21:16 Message: Logged In: YES user_id=234623 Confirmed that it is fixed in 2.3c2. My python testcase now runs in 0.096 secs. Would anyone happen to know what exactly changed for gethostbyname() calls on OSX btw. 2.2 and 2.3? I ask because PHP 4.3.2 seems to suffer from the very same problem! ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-06-16 15:12 Message: Logged In: YES user_id=45365 Hmm. It looks like something that is fixed in 2.3. When running the example with Apple's /usr/bin/python 2.2 I get "0.6942 secs elapsed". When I run it with 2.3b2 from CVS I get "0.0069 secs elapsed". Could this be an effect of the gethostbyname() mods that were done for numeric addresses? Yes, it seems it could be. 1000 calls to gethostbyname("192.168.1.60") cost 7.4 seconds in Python 2.2, while 2.3b2 needs only 0.02 seconds. I don't know whether these fixes can be backported to 2.2, though (nor even exactly what they are:-) ---------------------------------------------------------------------- Comment By: Matt Kangas (mkangas) Date: 2003-06-15 00:21 Message: Logged In: YES user_id=234623 "otool -L" (similar to Linux's ldd) shows the following for my freshly-built Python 2.2.3 interpreter: drinkycrow:Python-2.2.3$ otool -L python.exe python.exe: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 63.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 14.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 462.0.0) drinkycrow:Python-2.2.3$ ./python.exe Python 2.2.3 (#2, Jun 14 2003, 17:58:35) [GCC 3.1 20020420 (prerelease)] on darwin -------------------------------------- I added the following CFLAGS line to my makefile: CFLAGS = -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -framework System -framework CoreServices -framework Foundation These are, AFAIK, all of the relevant options used when building _socket.so and python.exe. (See attached "build_notes.txt" for full details) ------------------------------------------ How does the C test-case perform now? Slower than before, but still an order of magnitude faster than the Python code! drinkycrow:udp_test_py$ make clean; make rm socktest gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -no-cpp-precomp -framework System-framework CoreServices -framework Foundation socktest.c -o socktest socktest.c: In function `main': socktest.c:21: warning: implicit declaration of function `bzero' socktest.c:25: warning: implicit declaration of function `inet_pton' socktest.c:30: warning: implicit declaration of function `exit' socktest.c:35: warning: implicit declaration of function `strlen' socktest.c:46: warning: implicit declaration of function `close' drinkycrow:udp_test_py$ time ./socktest opening socket sending 100 packets .................................................................................................... closing... done! real 0m0.164s user 0m0.030s sys 0m0.040s drinkycrow:udp_test_py$ otool -L socktest socktest: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 63.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 14.0.0) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 462.0.0) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-06-14 08:55 Message: Logged In: YES user_id=21627 Can you try to link your C program with the same libraries that python is linked with, and compile it with the same command line options that socketmodule is compiled with? My first guess is that enabling pthreads may have an effect. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=746895&group_id=5470 From noreply@sourceforge.net Mon Jul 28 00:04:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 16:04:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 12:35 Message generated for change (Comment added) made by theaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2003-07-27 23:04 Message: Logged In: YES user_id=827666 Hi. I just thought I'd mention that I got the same results with 2.3c2. Tim ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2003-07-22 03:09 Message: Logged In: YES user_id=827666 Hello. I just downloaded 2.3c1. I failed test_time as well. I was going to submit a new bug, but then I saw this thread. I hope this is the right place. test_time test test_time failed -- Traceback (most recent call last): File "/home/tim/Download/Python-2.3c1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/tim/Download/Python-2.3c1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST 227 tests OK. 1 test failed: test_time 27 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_email_codecs test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on linux2. make: *** [test] Error 1 For what it's worth, time seems to work... $ ./python -c 'import time; print time.tzname' ('EST', 'EDT') $ cat /proc/version Linux version 2.4.20 (root@mrbun) (gcc version 2.95.3 20010315 (release)) #11 Sat Nov 30 05:52:58 EST 2002 Tim ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-13 02:28 Message: Logged In: YES user_id=357491 I uploaded a new version of the patch. Give it a try and see what happens if you could. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-10 17:11 Message: Logged In: YES user_id=357491 Barry says you need to do the following to truly test the patch: - check out the head - make distclean - apply the patch - autoreconf - ./configure --with-pydebug - make test Apparently autoreconf regenerates something for autoconf and that has to be done. Learn something new everyday. Can you give that a shot, Torsten? If that still fails it is going to take some work to figure this one out. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-10 07:58 Message: Logged In: YES user_id=269193 no, sorry, no success! * re-compiled python, as expected the test failed again. * patch -p0 <../tzset4.diff * made a "make distclean" * ./configure again, looked nice, no chached stuff. * make * make test >>> failed again !!! anything i could check to help? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-10 04:37 Message: Logged In: YES user_id=80475 Tonight, test_time also failed for me and then worked on the next pass. Am using WinME and Py2.3b2+. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-09 18:30 Message: Logged In: YES user_id=269193 sorry, problem! hard drive scambled. i have to re-install python anyway. i will see if the test fails again, and then i try to apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 17:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 05:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-01 02:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 17:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 15:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Mon Jul 28 00:34:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 16:34:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-778558 ] Malformed HTML in the FAQ Wizard Message-ID: Bugs item #778558, was opened at 2003-07-27 13:52 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778558&group_id=5470 Category: Demos and Tools >Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Smith (johnjsmith) >Assigned to: Skip Montanaro (montanaro) Summary: Malformed HTML in the FAQ Wizard Initial Comment: Python: 2.3c2 The last line of Tools/faqwiz/faqw.py prints timing statistics *after* the end of the output as indicated by the . This line would be better kept commented out in the distribution. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-27 18:34 Message: Logged In: YES user_id=44345 Thanks for the report. It's a bit late in the 2.3 release cycle to fix this now. I'll simply remove it for 2.3.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778558&group_id=5470 From noreply@sourceforge.net Mon Jul 28 02:28:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 18:28:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-778681 ] struct does not pad to alignment Message-ID: Bugs item #778681, was opened at 2003-07-27 21: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=778681&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matt Behrens (mattbehrens) Assigned to: Nobody/Anonymous (nobody) Summary: struct does not pad to alignment Initial Comment: Given this C code: --- struct x { int a; char b; }; int main() { printf("sizeof(x)=%d\n", sizeof(struct x)); } --- And its Python counterpart: --- import struct print "calcsize(\iB\)=%d" % struct.calcsize("iB") --- On Intel (x86) Linux, Python 2.3b2+ (#2, Jul 5 2003, 11:28:28) [GCC 3.3.1 20030626 (Debian prerelease)] on linux2, the former shows 8 while the latter 5. I'm working with struct cdrom_tocentry from linux/include.h, and if I use the results of struct.pack, I get a string that's three bytes too short. Whether that is an actual issue or not depends on whether Linux expects to be able to use the entire 8 bytes in an ioctl or not, I suppose. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778681&group_id=5470 From noreply@sourceforge.net Mon Jul 28 07:18:59 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 27 Jul 2003 23:18:59 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-778763 ] Optional type enforcement Message-ID: Feature Requests item #778763, was opened at 2003-07-28 01:18 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=778763&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt Perry (occupant4) Assigned to: Nobody/Anonymous (nobody) Summary: Optional type enforcement Initial Comment: One of the things that makes Python easy to code in is the fact that you don't have to explicitly declare the types of variables, or associate a specific type with a variable. However, this can potentially lead to somewhat confusing and hard-to-maintain code, not to mention make it easier to introduce bugs. An idea struck me that it might be possible to combine the power and safety of a strictly type-checked language with the speed and ease of coding of Python. Normal variables as they stand now would be unaffected by this feature, and retain their polymorphic type capabilities. Allow the programmer to optionally declare the type of a variable somehow, be it with the C-like syntax "int x", or Pascal's (I think?) "x: int", or a new syntactic representation. Python could then issue a TypeError if the program attempts to assign a non-int to x. Obviously this feature could apply to any data type, such as string, list, or perhaps user-defined classes. Class member variables can be declared as now in the class definition body, with the same syntax to specify a type, ie: class Test: int x = 5 string name = "test" untyped = None In addition, adding a type specifier to a function's parameters could serve another means of distinguishing it from other functions, which could allow function overloading, ie: def double(int x): return 2*x def double(string x): return x + ' ' + x Advantages: - clarifies the author's intention in writing code, and could help prevent confusion as to what type a variable/parameter is. - helps prevent bugs due to type mistakes - doesn't interfere with existing code or coding style, as dynamically typed variables are still allowed - could allow function overloading if it was wanted Disadvantages: - implementing a type checker could be difficult? - potentially pollutes namespace with extra keywords like 'string' or 'list'. may need to choose different keywords. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778763&group_id=5470 From noreply@sourceforge.net Mon Jul 28 08:10:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 00:10:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-778400 ] IDLE hangs when selecting "Edit with IDLE" from explorer Message-ID: Bugs item #778400, was opened at 2003-07-27 12:32 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778400&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE hangs when selecting "Edit with IDLE" from explorer Initial Comment: IDLE editor window hangs when right clicking a file and selecting "Edit with IDLE" Steps to reproduce: o Open IDLE o Open explorer o Right click on a .py file o Choose "Edit with IDLE" A new IDLE edit window opens but it is not responding. The original (shell) IDLE window works fine. If you do the above without opening an IDLE shell it works fine. My system is win2k on IBM T30 (LapTop). ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2003-07-28 10:10 Message: Logged In: YES user_id=358087 When I change idle.pyw from from idlelib.PyShell import main to import idlelib.PyShell idlelib.PyShell.main() I get a responsive IDLE edit window + a new shell window. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-27 19:53 Message: Logged In: YES user_id=31435 Assigned to Kurt. On Win2K the steps above don't create a problem for me, but I get a frozen window if I repeat the last two steps. The whole failing sequence for me on a Win2K desktop box: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" o Right click on another .py file o Choose "Edit with IDLE" On Win98SE, the first "Edit with IDLE" works fine. The second "Edit with IDLE" opens a new shell window but not a window for the selected .py file. Third and subsequent "Edit with IDLE" steps have no visible effect (neither a new shell nor a new edit window open). Something is left in a hosed state then: if I close all the open IDLE windows, and try "Edit with IDLE" again, nothing visible happens. The Win98SE task manager (Ctrl+Alt+Del) doesn't show any Python processes running at that point, and neither does WinTop. It's still possible to start another IDLE, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778400&group_id=5470 From noreply@sourceforge.net Mon Jul 28 09:36:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 01:36:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-778799 ] scripts destination directory not on default path Message-ID: Bugs item #778799, was opened at 2003-07-28 18: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=778799&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: scripts destination directory not on default path Initial Comment: A distutils script that uses the 'scripts' directive will install the scripts in /Library/Frameworks/Versions/2.3/bin This directory is not on the path, and no documentation explains how to *put* it on the path. The end result is that 3rd party python libraries that install command line utilities don't work out of the box. If we need to have scripts and stuff dual homed in /Library/Frameworks/Versions/2.3/bin and /usr/local/bin, distutils will need to be patched to maintain the symlinks (although I personally feel putting anything in /usr/local/bin is a bad idea...). This of course will not be possible for the 2.3.0 release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778799&group_id=5470 From noreply@sourceforge.net Mon Jul 28 10:00:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 02:00:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-778804 ] CHIHTTPServer connat manage cgi in sub directories Message-ID: Bugs item #778804, was opened at 2003-07-28 11: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=778804&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent delft (vincent_delft) Assigned to: Nobody/Anonymous (nobody) Summary: CHIHTTPServer connat manage cgi in sub directories Initial Comment: With Python 2.2.2, CGIHTTPServer 1.32 on Linux Gentoo If I have a cgi script in cgi-bin it works wery well. If i copy the same script (with all same privileges) in cgi-bin/test (a subdirectory) I got the following message : "Error response Error code 403. Message: CGI script is not a plain file ('/cgi-bin/test'). Error code explanation: 403 = Request forbidden -- authorization will not help. " If I remove the "rest.find('/')" code functionality by forcing the result to -1 it works well (cfr here after) Can you explain the goal of such coding ? i = rest.find('/') + i=-1 if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translate_path(scriptname) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 From noreply@sourceforge.net Mon Jul 28 10:01:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 02:01:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-778804 ] CHIHTTPServer connat manage cgi in sub directories Message-ID: Bugs item #778804, was opened at 2003-07-28 11:00 Message generated for change (Settings changed) made by vincent_delft You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 Category: Python Library Group: Python 2.2.2 Status: Open Resolution: None Priority: 5 Submitted By: vincent delft (vincent_delft) >Assigned to: Raymond Hettinger (rhettinger) Summary: CHIHTTPServer connat manage cgi in sub directories Initial Comment: With Python 2.2.2, CGIHTTPServer 1.32 on Linux Gentoo If I have a cgi script in cgi-bin it works wery well. If i copy the same script (with all same privileges) in cgi-bin/test (a subdirectory) I got the following message : "Error response Error code 403. Message: CGI script is not a plain file ('/cgi-bin/test'). Error code explanation: 403 = Request forbidden -- authorization will not help. " If I remove the "rest.find('/')" code functionality by forcing the result to -1 it works well (cfr here after) Can you explain the goal of such coding ? i = rest.find('/') + i=-1 if i >= 0: script, rest = rest[:i], rest[i:] else: script, rest = rest, '' scriptname = dir + '/' + script scriptfile = self.translate_path(scriptname) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778804&group_id=5470 From noreply@sourceforge.net Mon Jul 28 11:52:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 03:52:41 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-778859 ] Make the generators working like Sather iterator Message-ID: Feature Requests item #778859, was opened at 2003-07-28 12:52 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=778859&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shasckaw Lionfaith (shasckaw) Assigned to: Nobody/Anonymous (nobody) Summary: Make the generators working like Sather iterator Initial Comment: Primarly, it would only be a syntaxic sugar. But it can lead to some unexpected opitmisations. The feature would allow this: def upto(first, last): x=first while x<=last: yield x x=x+1 x=upto(1, 10) try: while 1: print x.next() except StopIteration: print "End of loop" To be written like in Sather or something near it: def upto(first, last): #same definition as above loop: print upto!(1, 10) finally: print "End of loop" As you can see, it's shorter, smarter, and more easy to understand. The '!' in upto!(1, 10) is important to emphasize its rôle as a generator. The creators of Sather tell that this technique can lead to a very high optimisation of loops. I hope that this request will be deeply studied because it is really worth of it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778859&group_id=5470 From noreply@sourceforge.net Mon Jul 28 11:52:55 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 03:52:55 -0700 Subject: [Python-bugs-list] [ python-Bugs-778558 ] Malformed HTML in the FAQ Wizard Message-ID: Bugs item #778558, was opened at 2003-07-27 18:52 Message generated for change (Comment added) made by johnjsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778558&group_id=5470 Category: Demos and Tools Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: John J Smith (johnjsmith) Assigned to: Skip Montanaro (montanaro) Summary: Malformed HTML in the FAQ Wizard Initial Comment: Python: 2.3c2 The last line of Tools/faqwiz/faqw.py prints timing statistics *after* the end of the output as indicated by the . This line would be better kept commented out in the distribution. ---------------------------------------------------------------------- >Comment By: John J Smith (johnjsmith) Date: 2003-07-28 10:52 Message: Logged In: YES user_id=830565 Thanks. Note that, as of 2.3c2, the FAQ Wizard does not work at all (see bug number 777659). ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-27 23:34 Message: Logged In: YES user_id=44345 Thanks for the report. It's a bit late in the 2.3 release cycle to fix this now. I'll simply remove it for 2.3.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778558&group_id=5470 From noreply@sourceforge.net Mon Jul 28 12:58:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 04:58:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-777659 ] Uninitialized variable used in Tools/faqwiz/faqwiz.py Message-ID: Bugs item #777659, was opened at 2003-07-25 11:39 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777659&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: John J Smith (johnjsmith) >Assigned to: Skip Montanaro (montanaro) Summary: Uninitialized variable used in Tools/faqwiz/faqwiz.py Initial Comment: Python: 2.3rc2 The uninitialized variable tfn is used in Tools/faqwiz/faqwiz.py (lines 811, 833). ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-28 06:58 Message: Logged In: YES user_id=44345 The fix appears trivial. I'll check in the change after the 2.3 release. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-27 00:12 Message: Logged In: YES user_id=80475 Guido, these lines were from your patch in 2002. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777659&group_id=5470 From noreply@sourceforge.net Mon Jul 28 13:22:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 05:22:03 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-778859 ] Make the generators working like Sather iterator Message-ID: Feature Requests item #778859, was opened at 2003-07-28 06:52 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778859&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shasckaw Lionfaith (shasckaw) Assigned to: Nobody/Anonymous (nobody) Summary: Make the generators working like Sather iterator Initial Comment: Primarly, it would only be a syntaxic sugar. But it can lead to some unexpected opitmisations. The feature would allow this: def upto(first, last): x=first while x<=last: yield x x=x+1 x=upto(1, 10) try: while 1: print x.next() except StopIteration: print "End of loop" To be written like in Sather or something near it: def upto(first, last): #same definition as above loop: print upto!(1, 10) finally: print "End of loop" As you can see, it's shorter, smarter, and more easy to understand. The '!' in upto!(1, 10) is important to emphasize its rôle as a generator. The creators of Sather tell that this technique can lead to a very high optimisation of loops. I hope that this request will be deeply studied because it is really worth of it. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 08:22 Message: Logged In: YES user_id=12800 The Pythonic way to write the latter (after the def) is: for x in upto(1, 10): print x else: print 'end of loop' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778859&group_id=5470 From noreply@sourceforge.net Mon Jul 28 13:55:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 05:55:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-778119 ] Shared Python Library installed without link Message-ID: Bugs item #778119, was opened at 2003-07-26 17:59 Message generated for change (Comment added) made by achimgaedke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778119&group_id=5470 Category: Installation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Achim Gaedke (achimgaedke) Assigned to: Nobody/Anonymous (nobody) Summary: Shared Python Library installed without link Initial Comment: Hi! I've read the Changes of python2.3c2 and found good news of a shared python library. It is installed at: /usr/local/lib/libpython2.3.so.1.0 For compatibility most installer link such libraries with full version number to a simple name: libpython2.3.so . Maybe you can add such a feature to the Makefile. My system: Redhat-8.0 with all available patches applied. Python Version: Python2.3c2 source distribution ---------------------------------------------------------------------- >Comment By: Achim Gaedke (achimgaedke) Date: 2003-07-28 14:55 Message: Logged In: YES user_id=246687 might be a follow up failure of: [ 701823 ] configure option --enable-shared make problems ---------------------------------------------------------------------- Comment By: Achim Gaedke (achimgaedke) Date: 2003-07-27 14:20 Message: Logged In: YES user_id=246687 No. To be more exact: I usually install new programs to /opt/prgname-version, so the example was a little bit unusual for me. As you suggested I executed as root: ldconfig -n /opt/Python-2.3c2/lib This should update the link, but not the ldso.cache (as stated in the man-page). But it does not work. Maybe, the SONAME of this library is too detailed: objdump -p /opt/Python-2.3c2/lib/libpython2.3.so.1.0|grep SONAME SONAME libpython2.3.so.1.0 Ok, I've changed soname (-Wl,-soname=libpython2.3.so) and now the link appears! ldconfig -vn /opt/Python-2.3c2/lib /opt/Python-2.3c2/lib: libpython2.3.so -> libpython2.3.so.1.0 (changed) One (hard)link is set in the build-directory. But it is not copied to the install directory. My suggestion is to change the Makefile: 1) -Wl,-soname should give the short name 2) Set a link or run ldconfig -n $(LIBDIR) ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-27 13:07 Message: Logged In: YES user_id=21627 Does the link appear if you run ldconfig? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778119&group_id=5470 From noreply@sourceforge.net Mon Jul 28 14:22:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 06:22:49 -0700 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-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@sourceforge.net Mon Jul 28 14:23:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 06:23:25 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-778859 ] Make the generators working like Sather iterator Message-ID: Feature Requests item #778859, was opened at 2003-07-28 12:52 Message generated for change (Comment added) made by shasckaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778859&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Shasckaw Lionfaith (shasckaw) Assigned to: Nobody/Anonymous (nobody) Summary: Make the generators working like Sather iterator Initial Comment: Primarly, it would only be a syntaxic sugar. But it can lead to some unexpected opitmisations. The feature would allow this: def upto(first, last): x=first while x<=last: yield x x=x+1 x=upto(1, 10) try: while 1: print x.next() except StopIteration: print "End of loop" To be written like in Sather or something near it: def upto(first, last): #same definition as above loop: print upto!(1, 10) finally: print "End of loop" As you can see, it's shorter, smarter, and more easy to understand. The '!' in upto!(1, 10) is important to emphasize its rôle as a generator. The creators of Sather tell that this technique can lead to a very high optimisation of loops. I hope that this request will be deeply studied because it is really worth of it. ---------------------------------------------------------------------- >Comment By: Shasckaw Lionfaith (shasckaw) Date: 2003-07-28 15:23 Message: Logged In: YES user_id=824691 My example was too simple, sorry. Here is a doc page about satheric iterators: http://www.gnu.org/software/sather/Doc/tutorial.html/iterators873.html And the next one is also pretty interesting. With the satheric way to write it, one would be able to do this: loop: a=range!(1,10) if test(a): b=range!(1,10) print "("+ a + "," + "b" + ")" My error is repaired now! :) The first iterator to stop stop the loop. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 14:22 Message: Logged In: YES user_id=12800 The Pythonic way to write the latter (after the def) is: for x in upto(1, 10): print x else: print 'end of loop' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=778859&group_id=5470 From noreply@sourceforge.net Mon Jul 28 15:47:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 07:47:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-778964 ] parameter confusion in 2.3c2 Message-ID: Bugs item #778964, was opened at 2003-07-28 21: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=778964&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) Summary: parameter confusion in 2.3c2 Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply@sourceforge.net Mon Jul 28 15:54:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 07:54:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-777867 ] test_ioctl fails Message-ID: Bugs item #777867, was opened at 2003-07-26 00:25 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-07-28 15:54 Message: Logged In: YES user_id=6656 This is deeply weird. The most likely scenario that some *other* test (or combination of tests, sigh) is tickling a bug in glibc that test_ioctl is revealing. Evidence for/against this could be acquired by adding '-r' to TESTOPTS and running make test a few times. But I still don't understand why running regrtest.py from the shell passes. Unless it's a Heisenbug, or just a flat out bug in the test. Hmm. Ten gets you one that it's test_fork1 that buggers it up. It seems exceedingly unlikely that this points to a real problem in Python's ioctl code. ioctl() is not the easiest thing in the world to write tests for... ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 13:20 Message: Logged In: YES user_id=52562 Okay, I added "-v" to TESTOPTS in Makefile. test_ioctl test_ioctl (test.test_ioctl.IoctlTests) ... FAIL test_ioctl_mutate (test.test_ioctl.IoctlTests) ... FAIL ====================================================================== FAIL: test_ioctl (test.test_ioctl.IoctlTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py", line 22, in test_ioctl self.assertEquals(pgrp, struct.unpack("i", r)[0]) File "/home/zooko/playground/python/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 32261 != 28460 ====================================================================== FAIL: test_ioctl_mutate (test.test_ioctl.IoctlTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py", line 31, in test_ioctl_mutate self.assertEquals(pgrp, buf[0]) File "/home/zooko/playground/python/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 32261 != 28460 ---------------------------------------------------------------------- Ran 2 tests in 0.002s FAILED (failures=2) test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-26 00:52 Message: Logged In: YES user_id=6656 Oh dear. Could you hack 'make test' to pass -v to regrtest? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 00:44 Message: Logged In: YES user_id=52562 I cut and pasted the unit test code and ran it, and it passed. So I suppose it's a bug in how "make test" invokes the test_ioctl unit test? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-26 00:33 Message: Logged In: YES user_id=6656 Can you dig? I.e. more info than "test_ioctl fails"... try running the code that test_ioctl runs and see what that does ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 00:33 Message: Logged In: YES user_id=52562 The stuff I posted when I opened this bug report was all from running "make test". I have now discovered the "regrtest.py" file and am experimenting with it. -s doesn't seem to work for test_ioctl.py: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py -v -s ./Lib/test/test_ioctl.py ./Lib/test/test_ioctl test ./Lib/test/test_ioctl crashed -- exceptions.ValueError: Empty module name Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) ValueError: Empty module name 1 test failed: ./Lib/test/test_ioctl Traceback (most recent call last): File "./Lib/test/regrtest.py", line 1005, in ? main() File "./Lib/test/regrtest.py", line 332, in main os.unlink(filename) OSError: [Errno 2] No such file or directory: '/tmp/pynexttest' But running regrtest.py by itself runs a bunch of tests including test_ioctl, apparently successfully: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py ... test_ioctl ... 224 tests OK. 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale So I guess this is an "issue" in the make target rather than in the ioctl code itself... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 From noreply@sourceforge.net Mon Jul 28 16:00:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 08:00:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-777867 ] test_ioctl fails Message-ID: Bugs item #777867, was opened at 2003-07-25 23:25 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-28 15:00 Message: Logged In: YES user_id=52562 It's always possible that I'm doing something very silly and not reporting it. But, as I am pressed for time, it would be really good if you could get a failure like this running on your own box. Hm. Maybe this means I should just upgrade my glibc. MAIN pion:~$ dpkg --status libc6 | grep ^Version Version: 2.3.1-16 Hm. Okay, I'll add -r to TESTOPTS and run lots of "make test". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-28 14:54 Message: Logged In: YES user_id=6656 This is deeply weird. The most likely scenario that some *other* test (or combination of tests, sigh) is tickling a bug in glibc that test_ioctl is revealing. Evidence for/against this could be acquired by adding '-r' to TESTOPTS and running make test a few times. But I still don't understand why running regrtest.py from the shell passes. Unless it's a Heisenbug, or just a flat out bug in the test. Hmm. Ten gets you one that it's test_fork1 that buggers it up. It seems exceedingly unlikely that this points to a real problem in Python's ioctl code. ioctl() is not the easiest thing in the world to write tests for... ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 12:20 Message: Logged In: YES user_id=52562 Okay, I added "-v" to TESTOPTS in Makefile. test_ioctl test_ioctl (test.test_ioctl.IoctlTests) ... FAIL test_ioctl_mutate (test.test_ioctl.IoctlTests) ... FAIL ====================================================================== FAIL: test_ioctl (test.test_ioctl.IoctlTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py", line 22, in test_ioctl self.assertEquals(pgrp, struct.unpack("i", r)[0]) File "/home/zooko/playground/python/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 32261 != 28460 ====================================================================== FAIL: test_ioctl_mutate (test.test_ioctl.IoctlTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py", line 31, in test_ioctl_mutate self.assertEquals(pgrp, buf[0]) File "/home/zooko/playground/python/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 32261 != 28460 ---------------------------------------------------------------------- Ran 2 tests in 0.002s FAILED (failures=2) test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-25 23:52 Message: Logged In: YES user_id=6656 Oh dear. Could you hack 'make test' to pass -v to regrtest? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 23:44 Message: Logged In: YES user_id=52562 I cut and pasted the unit test code and ran it, and it passed. So I suppose it's a bug in how "make test" invokes the test_ioctl unit test? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-25 23:33 Message: Logged In: YES user_id=6656 Can you dig? I.e. more info than "test_ioctl fails"... try running the code that test_ioctl runs and see what that does ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-25 23:33 Message: Logged In: YES user_id=52562 The stuff I posted when I opened this bug report was all from running "make test". I have now discovered the "regrtest.py" file and am experimenting with it. -s doesn't seem to work for test_ioctl.py: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py -v -s ./Lib/test/test_ioctl.py ./Lib/test/test_ioctl test ./Lib/test/test_ioctl crashed -- exceptions.ValueError: Empty module name Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) ValueError: Empty module name 1 test failed: ./Lib/test/test_ioctl Traceback (most recent call last): File "./Lib/test/regrtest.py", line 1005, in ? main() File "./Lib/test/regrtest.py", line 332, in main os.unlink(filename) OSError: [Errno 2] No such file or directory: '/tmp/pynexttest' But running regrtest.py by itself runs a bunch of tests including test_ioctl, apparently successfully: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py ... test_ioctl ... 224 tests OK. 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale So I guess this is an "issue" in the make target rather than in the ioctl code itself... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 From noreply@sourceforge.net Mon Jul 28 16:06:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 08:06:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-777867 ] test_ioctl fails Message-ID: Bugs item #777867, was opened at 2003-07-26 00:25 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 Category: None Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: test_ioctl test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ... 223 tests OK. 1 test failed: test_ioctl 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale make: *** [test] Error 1 My system: * Python from CVS: Python 2.3c1 (#1, Jul 23 2003, 08:31:24) * Debian testing/unstable * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003 i686 unknown unknown GNU/Linux * gcc (GCC) 3.3.1 20030626 (Debian prerelease) * AMD Athlon XP 1600+ ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-07-28 16:06 Message: Logged In: YES user_id=6656 Heh, yes it certainly would be easier if I (or anyone else) could reproduce this. However, this is the first I've heard of it, and I'd have thought/hoped that there are other people running the release candidates on Debian testing... glibc is very much a guess scapegoat, don't jeopardize your system just for me. I suggested the '-r' thing because it's the sort of thing that can be done in the background. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-28 16:00 Message: Logged In: YES user_id=52562 It's always possible that I'm doing something very silly and not reporting it. But, as I am pressed for time, it would be really good if you could get a failure like this running on your own box. Hm. Maybe this means I should just upgrade my glibc. MAIN pion:~$ dpkg --status libc6 | grep ^Version Version: 2.3.1-16 Hm. Okay, I'll add -r to TESTOPTS and run lots of "make test". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-28 15:54 Message: Logged In: YES user_id=6656 This is deeply weird. The most likely scenario that some *other* test (or combination of tests, sigh) is tickling a bug in glibc that test_ioctl is revealing. Evidence for/against this could be acquired by adding '-r' to TESTOPTS and running make test a few times. But I still don't understand why running regrtest.py from the shell passes. Unless it's a Heisenbug, or just a flat out bug in the test. Hmm. Ten gets you one that it's test_fork1 that buggers it up. It seems exceedingly unlikely that this points to a real problem in Python's ioctl code. ioctl() is not the easiest thing in the world to write tests for... ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 13:20 Message: Logged In: YES user_id=52562 Okay, I added "-v" to TESTOPTS in Makefile. test_ioctl test_ioctl (test.test_ioctl.IoctlTests) ... FAIL test_ioctl_mutate (test.test_ioctl.IoctlTests) ... FAIL ====================================================================== FAIL: test_ioctl (test.test_ioctl.IoctlTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py", line 22, in test_ioctl self.assertEquals(pgrp, struct.unpack("i", r)[0]) File "/home/zooko/playground/python/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 32261 != 28460 ====================================================================== FAIL: test_ioctl_mutate (test.test_ioctl.IoctlTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py", line 31, in test_ioctl_mutate self.assertEquals(pgrp, buf[0]) File "/home/zooko/playground/python/python/dist/src/Lib/unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: 32261 != 28460 ---------------------------------------------------------------------- Ran 2 tests in 0.002s FAILED (failures=2) test test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-26 00:52 Message: Logged In: YES user_id=6656 Oh dear. Could you hack 'make test' to pass -v to regrtest? ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 00:44 Message: Logged In: YES user_id=52562 I cut and pasted the unit test code and ran it, and it passed. So I suppose it's a bug in how "make test" invokes the test_ioctl unit test? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-26 00:33 Message: Logged In: YES user_id=6656 Can you dig? I.e. more info than "test_ioctl fails"... try running the code that test_ioctl runs and see what that does ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2003-07-26 00:33 Message: Logged In: YES user_id=52562 The stuff I posted when I opened this bug report was all from running "make test". I have now discovered the "regrtest.py" file and am experimenting with it. -s doesn't seem to work for test_ioctl.py: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py -v -s ./Lib/test/test_ioctl.py ./Lib/test/test_ioctl test ./Lib/test/test_ioctl crashed -- exceptions.ValueError: Empty module name Traceback (most recent call last): File "./Lib/test/regrtest.py", line 394, in runtest the_package = __import__(abstest, globals(), locals(), []) ValueError: Empty module name 1 test failed: ./Lib/test/test_ioctl Traceback (most recent call last): File "./Lib/test/regrtest.py", line 1005, in ? main() File "./Lib/test/regrtest.py", line 332, in main os.unlink(filename) OSError: [Errno 2] No such file or directory: '/tmp/pynexttest' But running regrtest.py by itself runs a bunch of tests including test_ioctl, apparently successfully: HACK pion:~/playground/python/python/dist/src$ ./python ./Lib/test/regrtest.py ... test_ioctl ... 224 tests OK. 31 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_curses test_dbm test_email_codecs test_gdbm test_gl test_imgfile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound 4 skips unexpected on linux2: test_dbm test_bz2 test_gdbm test_locale So I guess this is an "issue" in the make target rather than in the ioctl code itself... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777867&group_id=5470 From noreply@sourceforge.net Mon Jul 28 16:15:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 08:15:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-778964 ] parameter confusion in 2.3c2 Message-ID: Bugs item #778964, was opened at 2003-07-28 16:47 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) Summary: parameter confusion in 2.3c2 Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 17:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply@sourceforge.net Mon Jul 28 19:36:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 11:36:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-775964 ] fix test_grp failing on RedHat 6.2 Message-ID: Bugs item #775964, was opened at 2003-07-23 01:07 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Barry A. Warsaw (bwarsaw) Summary: fix test_grp failing on RedHat 6.2 Initial Comment: I didn't really think this should go into 2.3, but I'll let you make the decision. This patch fixes the test_grp failure on RedHat 6.2/Alpha (asmodean) in the snake-farm. I thought it was specific to RH 6.2, apparently it's not. If you add a + as the last line in /etc/group the test will fail on RH 9 too. Walter Doerwald may know more about how best to fix this. I'm not certain if it's really a problem in the extension module or the test. If you want to fix the test, the patch is included here: def check_value(self, value): # check that a grp tuple has the entries and # attributes promised by the docs + if value == ('+', None, 0, []): + # some libc's return the last line of + + return ---------------------------------------------------------------------- >Comment By: Walter Dörwald (doerwalter) Date: 2003-07-28 20:36 Message: Logged In: YES user_id=89016 pwdmodule.c hasn't changed in 7 months, so I'd say this is a problem with the test. But ('+', None, 0, []) doesn't seem to be a valid entry, so (although it's not a bug in Python) maybe Python should hide this entry. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-27 18:22 Message: Logged In: YES user_id=12800 Remind me what + on a line means in /etc/group. "man group" on RH9 gives no clue. I'm still nervous about it, can we defer until 2.3.1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 From noreply@sourceforge.net Mon Jul 28 21:27:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 13:27:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-779147 ] FutureWarning in Carbon/Controls.py Message-ID: Bugs item #779147, was opened at 2003-07-28 13: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=779147&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kevin Altis (kasplat) Assigned to: Jack Jansen (jackjansen) Summary: FutureWarning in Carbon/Controls.py Initial Comment: While building a wxPython standalone with bundlebuilder.py I got the following warning that I hadn't seen before. Just in case this is an issue for 2.3rc2 I thought I should bring it up here. Finding module dependencies /Library/Frameworks/Python.framework/Versions/2.3/lib/p ython2.3/plat-mac/Carbon/Controls.py:11: FutureWarning: hex/oct constants > sys.maxint will return positive values in Python 2.4 and up kDataBrowserClientPropertyFlagsMask = 0xFF000000 ka ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779147&group_id=5470 From noreply@sourceforge.net Mon Jul 28 21:35:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 13:35:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-779151 ] genlocations.py only works for OS9 users and jack ;) Message-ID: Bugs item #779151, was opened at 2003-07-28 16:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779151&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: genlocations.py only works for OS9 users and jack ;) Initial Comment: --- I'm inlining snippets of code from plat-mac/ bgenlocations.py --- if sys.platform == 'mac': # For MacPython we know where it is def _pardir(p): return os.path.split(p)[0] BGENDIR=os.path.join(sys.prefix, "Tools", "bgen", "bgen") else: # for unix-Python we don't know, please set it yourself. BGENDIR="/Users/jack/src/python/Tools/bgen/bgen" With unix python using Jack's 2.3rc2 installer, BGENDIR should be /Applications/MacPython-2.3/Extras/Tools/bgen # # Where to put the python definitions files. Note that, on unix-Python, # if you want to commit your changes to the CVS repository this should refer to # your source directory, not your installed directory. # if sys.platform == 'mac': TOOLBOXDIR=os.path.join(sys.prefix, "Lib", "plat-mac", "Carbon") else: TOOLBOXDIR="/Users/jack/src/python/Lib/plat-mac/ Carbon" TOOLBOXDIR should point somewhere reasonable. maybe os.path.expanduser('~/src/python/')... You should be able to override this without editing your python installation. For example, it could print a warning instead of raising an exception.. look somewhere in sys.path for an override file, etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779151&group_id=5470 From noreply@sourceforge.net Mon Jul 28 21:43:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 13:43:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-779153 ] bgen requires Universal Headers, not OS X dev headers Message-ID: Bugs item #779153, was opened at 2003-07-28 16:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779153&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: bgen requires Universal Headers, not OS X dev headers Initial Comment: bgen currently requires Universal Headers, but doesn't really make that explicitly clear. Universal headers do not come with the OS X developer tools. It's not terribly hard to convert the bgen suites to expect OS X style headers. Attached is an example that extends some of the Qt wrapper functionality for a project that I needed. It has been modified to accept OS X developer tools headers (but not Universal Headers). It would be possible to make generators that could use either, depending on which is found, but that was not one of my goals. Note that macglue.h was not changed, just included so it'll build outside of the python source tree (if bgenlocations.TOOLBOXDIR is appropriately changed as well, of course). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779153&group_id=5470 From noreply@sourceforge.net Mon Jul 28 21:48:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 13:48:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-779154 ] PackageManager maintainer missing documentation Message-ID: Bugs item #779154, was opened at 2003-07-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=779154&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager maintainer missing documentation Initial Comment: I was unable to locate maintainer documentation on the schema of the PackageManager database ( http:// python.org/packman/version-0.3/darwin-6.6- Power_Macintosh.plist ). I was also unable to locate documentation for how a maintainer would build one of these databases (particularly for binary packages). However, I was able to reverse engineer it by looking at the Package Manager/PIMP sourcecode, and I've prototyped an example script for building a binary package and spitting out a template for its entry in the plist. It's attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779154&group_id=5470 From noreply@sourceforge.net Mon Jul 28 21:49:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 13:49:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-779158 ] Additional PackageManger functionality Message-ID: Bugs item #779158, was opened at 2003-07-28 16: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=779158&group_id=5470 Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Additional PackageManger functionality Initial Comment: PackageManager should probably let you choose a tarball/ zip/folder on disk (or drag + drop) and look for a setup.py that it would do the Usual Thing with. Perhaps also let you choose an arbitrary .py file and scan for 'distutils' -- but I've only seen a called-something-other-than-setup.py distutils installer in one package (it had multiple setup-prefixed installers that installed different related modules, and an annoying no-op setup.py.. so I would say this is a bug on his part). PackageManager should be refactored to be responsive and non-blocking (i.e. threaded or forking). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779158&group_id=5470 From noreply@sourceforge.net Mon Jul 28 21:51:03 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 13:51:03 -0700 Subject: [Python-bugs-list] [ python-Bugs-779158 ] Additional PackageManger functionality Message-ID: Bugs item #779158, was opened at 2003-07-28 16:49 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779158&group_id=5470 Category: Macintosh Group: Python 2.4 >Status: Deleted Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: Additional PackageManger functionality Initial Comment: PackageManager should probably let you choose a tarball/ zip/folder on disk (or drag + drop) and look for a setup.py that it would do the Usual Thing with. Perhaps also let you choose an arbitrary .py file and scan for 'distutils' -- but I've only seen a called-something-other-than-setup.py distutils installer in one package (it had multiple setup-prefixed installers that installed different related modules, and an annoying no-op setup.py.. so I would say this is a bug on his part). PackageManager should be refactored to be responsive and non-blocking (i.e. threaded or forking). ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2003-07-28 16:51 Message: Logged In: YES user_id=139309 this is supposed to be a feature req, oops ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779158&group_id=5470 From noreply@sourceforge.net Mon Jul 28 21:52:20 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 13:52:20 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-779160 ] Enhance PackageManager functionality Message-ID: Feature Requests item #779160, was opened at 2003-07-28 16:52 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=779160&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance PackageManager functionality Initial Comment: PackageManager should probably let you choose a tarball/ zip/folder on disk (or drag + drop) and look for a setup.py that it would do the Usual Thing with. Perhaps also let you choose an arbitrary .py file and scan for 'distutils' -- but I've only seen a called-something-other-than-setup.py distutils installer in one package (it had multiple setup-prefixed installers that installed different related modules, and an annoying no-op setup.py.. so I would say this is a bug on his part). PackageManager should be refactored to be responsive and non-blocking (i.e. threaded or forking). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=779160&group_id=5470 From noreply@sourceforge.net Mon Jul 28 22:10:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 14:10:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-779167 ] urllib proxy handling incomplete for MacOSX Message-ID: Bugs item #779167, was opened at 2003-07-28 23:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779167&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: urllib proxy handling incomplete for MacOSX Initial Comment: Urllib has code to handle both unix-style environment-based proxy definitions and mac-style Internet Config based ones (along with some others), but on MacOSX only the environment-style ones are enabled. It needs to use the IC-based ones too, as this is the way to access the settings made by the user through the System Preferences application. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779167&group_id=5470 From noreply@sourceforge.net Mon Jul 28 22:56:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 14:56:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-775964 ] fix test_grp failing on RedHat 6.2 Message-ID: Bugs item #775964, was opened at 2003-07-22 19:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Barry A. Warsaw (bwarsaw) Summary: fix test_grp failing on RedHat 6.2 Initial Comment: I didn't really think this should go into 2.3, but I'll let you make the decision. This patch fixes the test_grp failure on RedHat 6.2/Alpha (asmodean) in the snake-farm. I thought it was specific to RH 6.2, apparently it's not. If you add a + as the last line in /etc/group the test will fail on RH 9 too. Walter Doerwald may know more about how best to fix this. I'm not certain if it's really a problem in the extension module or the test. If you want to fix the test, the patch is included here: def check_value(self, value): # check that a grp tuple has the entries and # attributes promised by the docs + if value == ('+', None, 0, []): + # some libc's return the last line of + + return ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-28 17:56 Message: Logged In: YES user_id=33168 I don't recall what the + is for either. Does it have something to do with YP/NIS? I don't think this is really critical so I'm droping the priority. If pwdmodule.c is changed, it will be an interface change so it's questionable for 2.3.1. This was found on the snake farm, never reported by a user. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-28 14:36 Message: Logged In: YES user_id=89016 pwdmodule.c hasn't changed in 7 months, so I'd say this is a problem with the test. But ('+', None, 0, []) doesn't seem to be a valid entry, so (although it's not a bug in Python) maybe Python should hide this entry. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-27 12:22 Message: Logged In: YES user_id=12800 Remind me what + on a line means in /etc/group. "man group" on RH9 gives no clue. I'm still nervous about it, can we defer until 2.3.1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 From noreply@sourceforge.net Mon Jul 28 23:00:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 15:00:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-777597 ] socketmodule.c connection handling incorect on windows Message-ID: Bugs item #777597, was opened at 2003-07-25 11:01 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777597&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: socketmodule.c connection handling incorect on windows Initial Comment: The socketmodule.c code does not handle connection refused correctly. This is due to a different of operation on windows of select. The offending code is in internal_connect in the MS_WINDOWS ifdef. The code in should test exceptfds to check for connecttion refused. If this is so itshould call getsockopt(SOL_SOCKET, SO_ERROR,..) to get the error status. (Source microsoft Platform SDK) The suggested fix is shown below (untested) #ifdef MS_WINDOWS f (s->sock_timeout > 0.0) { if (res < 0 && WSAGetLastError() == WSAEWOULDBLOCK) { /* This is a mess. Best solution: trust select */ fd_set exfds; struct timeval tv; tv.tv_sec = (int)s->sock_timeout; tv.tv_usec = (int)((s->sock_timeout - tv.tv_sec) * 1e6); FD_ZERO(&exfds); FD_SET(s->sock_fd, &exfds); /* Platform SDK says so */ res = select(s->sock_fd+1, NULL, NULL, &exfds, &tv); if (res > 0) { if( FD_ISSET( &exfds ) ) { /* Get the real reason */ getsockopt(s->sock_fd,SOL_SOCKET,SO_ERROR,(char*)&res,sizeof(res)); } else { /* God knows how we got here */ res = 0; } } else if( res == 0 ) { res = WSAEWOULDBLOCK; } else { /* Not sure we should return the erro from select? */ res = WSAGetLastError(); } } } else if (res < 0) res = WSAGetLastError(); #else ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-28 18:00 Message: Logged In: YES user_id=33168 Garth could you produce a patch against 2.3c2 with your selected change and test it? It would help us a lot as we are all very overloaded. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777597&group_id=5470 From noreply@sourceforge.net Mon Jul 28 23:05:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 15:05:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-779151 ] bgenlocations.py only works for OS9 users and jack ;) Message-ID: Bugs item #779151, was opened at 2003-07-28 16:35 Message generated for change (Settings changed) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779151&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) >Summary: bgenlocations.py only works for OS9 users and jack ;) Initial Comment: --- I'm inlining snippets of code from plat-mac/ bgenlocations.py --- if sys.platform == 'mac': # For MacPython we know where it is def _pardir(p): return os.path.split(p)[0] BGENDIR=os.path.join(sys.prefix, "Tools", "bgen", "bgen") else: # for unix-Python we don't know, please set it yourself. BGENDIR="/Users/jack/src/python/Tools/bgen/bgen" With unix python using Jack's 2.3rc2 installer, BGENDIR should be /Applications/MacPython-2.3/Extras/Tools/bgen # # Where to put the python definitions files. Note that, on unix-Python, # if you want to commit your changes to the CVS repository this should refer to # your source directory, not your installed directory. # if sys.platform == 'mac': TOOLBOXDIR=os.path.join(sys.prefix, "Lib", "plat-mac", "Carbon") else: TOOLBOXDIR="/Users/jack/src/python/Lib/plat-mac/ Carbon" TOOLBOXDIR should point somewhere reasonable. maybe os.path.expanduser('~/src/python/')... You should be able to override this without editing your python installation. For example, it could print a warning instead of raising an exception.. look somewhere in sys.path for an override file, etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779151&group_id=5470 From noreply@sourceforge.net Mon Jul 28 23:06:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 15:06:05 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-779160 ] Enhance PackageManager functionality Message-ID: Feature Requests item #779160, was opened at 2003-07-28 16:52 Message generated for change (Settings changed) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=779160&group_id=5470 Category: Macintosh Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) >Assigned to: Jack Jansen (jackjansen) Summary: Enhance PackageManager functionality Initial Comment: PackageManager should probably let you choose a tarball/ zip/folder on disk (or drag + drop) and look for a setup.py that it would do the Usual Thing with. Perhaps also let you choose an arbitrary .py file and scan for 'distutils' -- but I've only seen a called-something-other-than-setup.py distutils installer in one package (it had multiple setup-prefixed installers that installed different related modules, and an annoying no-op setup.py.. so I would say this is a bug on his part). PackageManager should be refactored to be responsive and non-blocking (i.e. threaded or forking). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=779160&group_id=5470 From noreply@sourceforge.net Mon Jul 28 23:32:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 15:32:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-779191 ] BasicModuleLoader behaviour in Python 2.3c2 Message-ID: Bugs item #779191, was opened at 2003-07-28 22: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=779191&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Selim Tuvi (stuvi) Assigned to: Nobody/Anonymous (nobody) Summary: BasicModuleLoader behaviour in Python 2.3c2 Initial Comment: Hi I am using the BasicModuleLoader class from the ihooks module and noticed that it behaves differently based on whether it is used from a script vs. from the Python command line. Here is the transcript of my session: C:\projects\Online\repos>type testModule.py C:\projects\Online\repos>cd ..\testsuite C:\projects\Online\testsuite>type impTest.py from ihooks import BasicModuleLoader import os os.chdir('../repos') ml = BasicModuleLoader() modstuff = ml.find_module('testModule') print modstuff C:\projects\Online\testsuite>python impTest.py None C:\projects\Online\testsuite>python Python 2.3c2 (#45, Jul 24 2003, 21:23:54) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from ihooks import BasicModuleLoader >>> import os >>> os.chdir('../repos') >>> ml = BasicModuleLoader() >>> modstuff = ml.find_module('testModule') >>> print modstuff (, 'testModule.py', ('.py', ' U', 1)) >>> ^Z C:\projects\Online\testsuite>cd ..\repos C:\projects\Online\repos>python ..\testsuite\impTest.py (, ' C:\projects\Online\repos\testModule.py', ('.py', 'U', 1)) C:\projects\Online\repos> Explanation of the above session: I created an empty module called testModule.py and stored it in c:\projects\Online\repos. Then I wrote the impTest.py script that tries to import it through the BasicModuleLoader. The impTest.py script resides in c:\projects\Online\testsuite directory. If I run the script from the testsuite directory it fails to find the module. If while I am in the testsuite directory I enter the contents of the impTest.py using the Python command line then it finds the module. Also if I run the impTest.py while I am in the repos directory then it finds it as well. In Python 2.2 this had worked in every case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779191&group_id=5470 From noreply@sourceforge.net Tue Jul 29 00:16:27 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 16:16:27 -0700 Subject: [Python-bugs-list] [ python-Bugs-779218 ] 2.3c2 test_pwd fails on Mac OS X 10.2.6 Message-ID: Bugs item #779218, was opened at 2003-07-28 23: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=779218&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill Janssen (janssen) Assigned to: Jack Jansen (jackjansen) Summary: 2.3c2 test_pwd fails on Mac OS X 10.2.6 Initial Comment: I get one test failure on Mac OS 10.2.6: test test_pwd failed -- Traceback (most recent call last): File "/Temporary Items/Python-2.3c2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) KeyError: 'getpwuid(): uid not found' The passwd entry on which it fails looks perfectly normal, AFAICS. We've got about 3500 entries in our passwd file, if that's of interest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779218&group_id=5470 From noreply@sourceforge.net Tue Jul 29 00:18:07 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 16:18:07 -0700 Subject: [Python-bugs-list] [ python-Bugs-779218 ] 2.3c2 test_pwd fails on Mac OS X 10.2.6 Message-ID: Bugs item #779218, was opened at 2003-07-28 23:16 Message generated for change (Settings changed) made by janssen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779218&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill Janssen (janssen) >Assigned to: Walter Dörwald (doerwalter) Summary: 2.3c2 test_pwd fails on Mac OS X 10.2.6 Initial Comment: I get one test failure on Mac OS 10.2.6: test test_pwd failed -- Traceback (most recent call last): File "/Temporary Items/Python-2.3c2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) KeyError: 'getpwuid(): uid not found' The passwd entry on which it fails looks perfectly normal, AFAICS. We've got about 3500 entries in our passwd file, if that's of interest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779218&group_id=5470 From noreply@sourceforge.net Tue Jul 29 00:24:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 16:24:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-775964 ] fix test_grp failing on RedHat 6.2 Message-ID: Bugs item #775964, was opened at 2003-07-22 18:07 Message generated for change (Comment added) made by jbrouwers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Barry A. Warsaw (bwarsaw) Summary: fix test_grp failing on RedHat 6.2 Initial Comment: I didn't really think this should go into 2.3, but I'll let you make the decision. This patch fixes the test_grp failure on RedHat 6.2/Alpha (asmodean) in the snake-farm. I thought it was specific to RH 6.2, apparently it's not. If you add a + as the last line in /etc/group the test will fail on RH 9 too. Walter Doerwald may know more about how best to fix this. I'm not certain if it's really a problem in the extension module or the test. If you want to fix the test, the patch is included here: def check_value(self, value): # check that a grp tuple has the entries and # attributes promised by the docs + if value == ('+', None, 0, []): + # some libc's return the last line of + + return ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-28 18:24 Message: Logged In: YES user_id=832557 The '+ ...' line at the end of the /etc/passwd file tells the system to also pickup information from the appropriate map in LDAP, or NIS (yellow pages). See also section 7.2 on this page: ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-28 16:56 Message: Logged In: YES user_id=33168 I don't recall what the + is for either. Does it have something to do with YP/NIS? I don't think this is really critical so I'm droping the priority. If pwdmodule.c is changed, it will be an interface change so it's questionable for 2.3.1. This was found on the snake farm, never reported by a user. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-28 13:36 Message: Logged In: YES user_id=89016 pwdmodule.c hasn't changed in 7 months, so I'd say this is a problem with the test. But ('+', None, 0, []) doesn't seem to be a valid entry, so (although it's not a bug in Python) maybe Python should hide this entry. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-27 11:22 Message: Logged In: YES user_id=12800 Remind me what + on a line means in /etc/group. "man group" on RH9 gives no clue. I'm still nervous about it, can we defer until 2.3.1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 From noreply@sourceforge.net Tue Jul 29 00:57:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 16:57:05 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-540952 ] Memory Usage Reporting Message-ID: Feature Requests item #540952, was opened at 2002-04-08 07:01 Message generated for change (Comment added) made by jbrouwers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Allan Crooks (amc1) Assigned to: Nobody/Anonymous (nobody) Summary: Memory Usage Reporting Initial Comment: I would personally like a way in Python to report how many bytes of memory that the interpreter is using (perhaps through the sys module)? If this sort of mechanism is added, then it may allow SoftReferences (a la Java) to be introduced, which would definitely be useful for memory sensitive caches... ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-28 18:57 Message: Logged In: YES user_id=832557 It would be useful to get some figure(s) about the memory usage of the current process. For example, just the 'high water mark' returned by sbrk(0) on uni* is very helpful in many cases. I tried the resource.getrusage(resource.RUSAGE_SELF) function but that does return all zero's in slice [2:6] on my uni* system. Not sure whether that is an artifact of the O/S or Python. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2002-04-10 09:03 Message: Logged In: YES user_id=29957 You _can_ do this for most O/Ss, true. The problem is that it's something that's extremely operating system specific, and, worse yet, varies significantly between operating system releases. Have a look at the source for the system utility 'top' one day - most of it is in the 'operating system specific' section, and there's all sorts of horrible horrible hoops you have to jump through for different releases. In addition, the notion of "how much memory is being used" isn't always that clear in the case of things like shared libraries. On the plus side, implementing this would move the HP/UX threading problem to #2 on the list of "most annoying operating-system dependent bugs". ---------------------------------------------------------------------- Comment By: Allan Crooks (amc1) Date: 2002-04-09 09:45 Message: Logged In: YES user_id=39733 Thanks for the response. Rather than having an internal way of figuring out how much memory is used, is there no external way that we can get the OS to return how big the process is? I know that it is less than elegant, and would have to have different platform-dependent code to do this, but it is still an idea. I know that Jython can quiz the VM to see how much memory is being used, and I'll assume that you can do that with different OS's as well... ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2002-04-08 11:38 Message: Logged In: YES user_id=31435 Allan, this isn't easy, so the cost/benefit ratio is high. For the most part, Python gets memory from the system malloc, and doesn't even try to keep track of it now; nor has it any idea how much overhead (padding, control bytes) the system malloc adds; nor is there a portable interface to C's malloc for finding out such things. Still, I agree it would be nice to have such things . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470 From noreply@sourceforge.net Tue Jul 29 01:27:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 17:27:41 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-764188 ] setvbuf for File object Message-ID: Feature Requests item #764188, was opened at 2003-07-01 15:21 Message generated for change (Comment added) made by jbrouwers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yue Luo (yueluo) Assigned to: Nobody/Anonymous (nobody) Summary: setvbuf for File object Initial Comment: I wonder if it is possible to add a new method setvbuf to File object. The method does the same as the setvbuf() in stdio.h. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-28 19:27 Message: Logged In: YES user_id=832557 There is already an optional bufsize argument to file(), open() and fdopen(). It allows you to specify unbuffered (0), line buffered (1), system default (-1) or buffered usage with a specific buffer size (>1). Are you requesting something different? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 01:57 Message: Logged In: YES user_id=21627 I see. Can you explain why invoking "python -u" is insufficient? ---------------------------------------------------------------------- Comment By: Yue Luo (yueluo) Date: 2003-07-07 18:14 Message: Logged In: YES user_id=806666 Sorry, I did not make myself clear. I just want to be able to change the buffer size or the buffer mode of a file object. Especially, I often want to change the standard output buffer mode to line buffer so that I can see the result immediately even when the output has been redirected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 17:08 Message: Logged In: YES user_id=21627 What buf argument would you like to pass? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 From noreply@sourceforge.net Tue Jul 29 01:39:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 17:39:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-779285 ] Carbon Event ReceiveNextEvent Message-ID: Bugs item #779285, was opened at 2003-07-29 00: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=779285&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Mark Kim (flabbergasted) Assigned to: Jack Jansen (jackjansen) Summary: Carbon Event ReceiveNextEvent Initial Comment: Carbon event, ReceiveNextEvent has an inList variable (const EventTypeSpec *inList) which can be specified as Null "if any event should cause this function to return." I've tried passing ReceiveNextEvent a 0, None/NULL an empty tuple/length two array, but it either throws an error, "TypeError: argument must be 2-item sequence, not None" or "int" or throws error type -9875. I looked at _CarbonEvtModule.c and it doesn't look like I can pass ReceiveNextEvent a Null because it demands a type of EventTypeSpec. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779285&group_id=5470 From noreply@sourceforge.net Tue Jul 29 02:44:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 18:44:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-779218 ] 2.3c2 test_pwd fails on Mac OS X 10.2.6 Message-ID: Bugs item #779218, was opened at 2003-07-28 18:16 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779218&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill Janssen (janssen) Assigned to: Walter Dörwald (doerwalter) Summary: 2.3c2 test_pwd fails on Mac OS X 10.2.6 Initial Comment: I get one test failure on Mac OS 10.2.6: test test_pwd failed -- Traceback (most recent call last): File "/Temporary Items/Python-2.3c2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) KeyError: 'getpwuid(): uid not found' The passwd entry on which it fails looks perfectly normal, AFAICS. We've got about 3500 entries in our passwd file, if that's of interest. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2003-07-28 20:44 Message: Logged In: YES user_id=44345 Is the password entry on which it fails a duplicate uid? I recall some problems when there were two user names with the same uid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779218&group_id=5470 From noreply@sourceforge.net Tue Jul 29 04:01:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 20:01:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-775964 ] fix test_grp failing on RedHat 6.2 Message-ID: Bugs item #775964, was opened at 2003-07-22 19:07 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Barry A. Warsaw (bwarsaw) Summary: fix test_grp failing on RedHat 6.2 Initial Comment: I didn't really think this should go into 2.3, but I'll let you make the decision. This patch fixes the test_grp failure on RedHat 6.2/Alpha (asmodean) in the snake-farm. I thought it was specific to RH 6.2, apparently it's not. If you add a + as the last line in /etc/group the test will fail on RH 9 too. Walter Doerwald may know more about how best to fix this. I'm not certain if it's really a problem in the extension module or the test. If you want to fix the test, the patch is included here: def check_value(self, value): # check that a grp tuple has the entries and # attributes promised by the docs + if value == ('+', None, 0, []): + # some libc's return the last line of + + return ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 23:01 Message: Logged In: YES user_id=12800 Thanks Jean for the independent verification. We'll fix this for Python 2.3.1. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-28 19:24 Message: Logged In: YES user_id=832557 The '+ ...' line at the end of the /etc/passwd file tells the system to also pickup information from the appropriate map in LDAP, or NIS (yellow pages). See also section 7.2 on this page: ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-28 17:56 Message: Logged In: YES user_id=33168 I don't recall what the + is for either. Does it have something to do with YP/NIS? I don't think this is really critical so I'm droping the priority. If pwdmodule.c is changed, it will be an interface change so it's questionable for 2.3.1. This was found on the snake farm, never reported by a user. ---------------------------------------------------------------------- Comment By: Walter Dörwald (doerwalter) Date: 2003-07-28 14:36 Message: Logged In: YES user_id=89016 pwdmodule.c hasn't changed in 7 months, so I'd say this is a problem with the test. But ('+', None, 0, []) doesn't seem to be a valid entry, so (although it's not a bug in Python) maybe Python should hide this entry. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-27 12:22 Message: Logged In: YES user_id=12800 Remind me what + on a line means in /etc/group. "man group" on RH9 gives no clue. I'm still nervous about it, can we defer until 2.3.1? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775964&group_id=5470 From noreply@sourceforge.net Tue Jul 29 04:04:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 20:04:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-779218 ] 2.3c2 test_pwd fails on Mac OS X 10.2.6 Message-ID: Bugs item #779218, was opened at 2003-07-28 19:16 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779218&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill Janssen (janssen) Assigned to: Walter Dörwald (doerwalter) Summary: 2.3c2 test_pwd fails on Mac OS X 10.2.6 Initial Comment: I get one test failure on Mac OS 10.2.6: test test_pwd failed -- Traceback (most recent call last): File "/Temporary Items/Python-2.3c2/Lib/test/test_pwd.py", line 42, in test_values self.assert_(pwd.getpwuid(e.pw_uid) in entriesbyuid[e.pw_uid]) KeyError: 'getpwuid(): uid not found' The passwd entry on which it fails looks perfectly normal, AFAICS. We've got about 3500 entries in our passwd file, if that's of interest. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 23:04 Message: Logged In: YES user_id=12800 This may also be a duplicate of bug # 775964, if you've got a + on a line in your /etc/passwd file (similar to the + in the /etc/group file discussed in that bug report). The + is a NIS/YP thing. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2003-07-28 21:44 Message: Logged In: YES user_id=44345 Is the password entry on which it fails a duplicate uid? I recall some problems when there were two user names with the same uid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779218&group_id=5470 From noreply@sourceforge.net Tue Jul 29 04:06:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 20:06:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-778964 ] parameter confusion in 2.3c2 Message-ID: Bugs item #778964, was opened at 2003-07-28 21:47 Message generated for change (Comment added) made by blaforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) Summary: parameter confusion in 2.3c2 Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Bill la Forge (blaforge) Date: 2003-07-29 10:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 22:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply@sourceforge.net Tue Jul 29 04:15:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 20:15:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-775985 ] Solaris error doing a print Message-ID: Bugs item #775985, was opened at 2003-07-22 20:18 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris error doing a print Initial Comment: As seen on Jeff Hobb's box. print "Registering '%s' (%s)" % (reg_contractid, fname) File "/usr/local/python-2.3/lib/python2.3/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) ValueError: Empty module name It seems that this shell has an empty "LANG" var setup - deleting this var seems to solve the problem. Looking in sysmodule.c, I see: if(codeset && isatty(fileno(stdin))){ (and a similar one for stdout). Should this be: if(codeset && *codeset && isatty(fileno(stdin))){ to prevent an empty name? Or better, should we check the encoding is actually installed? I will mail Jeff and ask him to attach comments on the version or anything else. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 23:15 Message: Logged In: YES user_id=12800 Before I can comment on this for 2.3 (and time is very quickly running out), can you provide: 1. a recipe to reproduce this on RH9 or other Linux? I tried in bash: % export LANG="" % ./python >>> print "foo" foo >>> i.e. nothing happened, so I'm sure I'm not doing this right. Also, any possibility of a test case? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-23 01:16 Message: Logged In: YES user_id=21627 I'm tempted to declare this a platform bug: Both Linux and later Solaris versions set the CODEPAGE to ASCII for an empty LANG (i.e. assume this is the "C" locale). Still, checking whether the encoding is present is probably a good idea. Unfortunately, it cannot be done right there, since loading of codecs does not work yet inside _PySys_Init. So as a work-around for 2.3, we should check for non-empty strings, and leave checking for supported encodings for 2.3.1. Patch attached. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-22 20:26 Message: Logged In: YES user_id=72656 python 2.3rc1, build --enable-shared. Solaris uname -a: SunOS knife 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra- 250 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 From noreply@sourceforge.net Tue Jul 29 04:20:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 20:20:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] IDLE/MAC: Command / Alt Bindings Don't Work Message-ID: Bugs item #768469, was opened at 2003-07-09 09:49 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE/MAC: Command / Alt Bindings Don't Work Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 23:20 Message: Logged In: YES user_id=12800 Is there something that I need to decide on for Python 2.3 final? Realize that time has nearly run out so only absolutely critical fixes (or documentation changes) can go in. I'm lowering the priority since there doesn't seem to be anything critical for 2.3 final. If you disagree, please raise priority back to 7 and describe exactly what you'd like for me to decide on. ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2003-07-16 11:49 Message: Logged In: YES user_id=24100 [tiagoh] >Using Apple's X11 beta 3 version, I am unable to access >any of the shortcuts that use the Alt key, including >the history keystrokes that recall past commands. >... >Is there any way to bypass this, allowing the Alt key >to be handled directly by IDLE? So, IDLE is running under X11? Perhaps you can bypass the undesirable behavior by changing the configuration of the X11 server. IDLE can not do anything to help in your situation, AFAIK, as it is X11 that is not giving the keystrokes to Tk. Have you tried using the native-windowing- system version of Tk, instead of Tk through X11? Mac keys bindings work smoothly, you can even override bindings if you like. [tiagoh again] >Unless I'm doing something stupid, this would be a serious >defect with respect to IDLE usability under MacOSX It is a serious defect to usability with respect to IDLE usability under MacOSX *under X11*. That is a big difference. Perhaps some information about using native Tk instead of through X11 would be good to add. Unless I am missing something about your software setup. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-15 23:14 Message: Logged In: YES user_id=149084 Lib/idlelib: Updated extend.txt (Rev 1.4), help.txt (Rev 1.10), and config-extensions.def (Rev 1.12) to partially correct the issues this bug raised. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-14 21:36 Message: Logged In: YES user_id=149084 I'd like to focus on the bug rather than an RFE for a new keyset. I'd suggest that you use [IDLE Modern] for a couple of months and then post your suggestion to the Idle-dev email list for comment. Please note that the Shift modifier isn't working because there is a bug (already reported on the IDLEfork Tracker). I have asked the IDLEfork Mac expert to take a look at this bug, which is that the Command-[something] bindings don't work (unless they happen to be default Tk bindings). There is also an issue with the use of Alt keys in the extensions. Originally, IDLE had the ability to define extension keybindings for each platform. These were eliminated in IDLEfork with, I believe, the intention to expand the configuration dialog to replace them. However, that has not as yet been accomplished. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 16:39 Message: Logged In: YES user_id=819035 File attachment doesn't seem to be working for me using Mozilla Firebird. Here is the tentative [IDLE Modern] key binding scheme, ordered by virtual event name: [IDLE Modern] beginning-of-line= center-insert= change-indentwidth= close-all-windows= close-window= comment-region= copy= cut= dedent-region= do-nothing= end-of-file= find-again= find-in-files= find-selection= find= goto-line= history-next= history-previous= indent-region= interrupt-execution= newline-and-indent= open-class-browser= open-module= open-new-window= open-window-from-file= paste= plain-newline-and-indent= print-window= python-context-help= python-docs= redo= remove-selection= replace= restart-shell= save-copy-of-window-as-file= save-window-as-file= save-window= select-all= smart-backspace= smart-indent= tabify-region= toggle-auto-coloring= toggle-tabs= uncomment-region= undo= untabify-region= view-restart= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 16:28 Message: Logged In: YES user_id=819035 Proposal for new key binding scheme =================================== Problem ------- Due to several reasons discussed in my previous messages, the 3 available key binding schemes for IDLE in MacOSX are not satisfactory for various reasons, the main one being that the Alt/Option modifier is preempted by MacOSX for accented characters and symbols, and the Command/Apple modifier is preempted by X11 for several shortcuts. Considering that IDLE is supposed to be a tool for beginners as well as for more advanced programmers, the key binding scheme for Windows (which is currently the default scheme) also has a few problems. Although all shortcuts in the [IDLE Classic Windows] key binding scheme seem to work, they use an inconsistent mix of modifier keys that hinders learning and makes it difficult to use in platforms where modifier keys work differently. Most of these shortcuts use the Control and Alt modifiers, but some shortcuts use 2 or more modifiers or a third modifier: Control modifier: close-all-windows= Alt/Meta modifier: close-window= Shift modifier: python-context-help= Several modifiers: redo= save-copy-of-window-as-file= Proposal -------- I propose to use a new key binding scheme that uses one single modifier key for all shortcuts in order to increase learnability and portability. The Control modifier is the natural choice for the standard modifier, since unlike the Alt, Command or Windows modifiers it is not usually used for standard OS shortcuts. I am attaching to this message my ~/.idlerc/config-keys.cfg file containing the bindings for this scheme, which I have tentatively named [IDLE Modern]. My hope is to have this scheme become one of the additional schemes shipped with IDLE, and perhaps even replace the [IDLE Classic Windows] scheme as the default scheme for IDLE on all platforms. Rationale --------- I tried to preserve most bindings that have become common in Mac, Windows and Linux applications, and change non-standard bindings to standard. I have also changed all bindings that use a modifier different from Control, sometimes using a similar binding (e.g. instead of for the <> virtual event), sometimes using a completely different binding. I strived to use only alphabetical keys, numerical keys and function keys, since other characters tend to shift according to which keyboard layout one is using. For instance, in the Portuguese keyboard layout the bracket characters have to accessed using a special modifier key, labeled AltGr (for Alt Graphics) together with a numeric key (AltGr-Key-7 and AltGr-Key-8), while the slash character has to be written using Shift-Key-7. This means that the standard bindings for the <>, <> and <> virtual events are difficult if not impossible to access with a Portuguese keyboard layout. One possible solution, which I chose many years ago, is to memorize the American keyboard layout and use that layout for all programming and command-line work, regardless of the actual labels on your keys. Although not really that difficult, this is a step that most people will understandably refuse to take. A more acceptable solution is to avoid using non-alphanumeric characters, which tend to vary a lot more from one layout to the other. I also tried to bind semantically similar virtual events to neighbouring keys, as is already the case with the standard clipboard shortcuts, which occupy 3 neighbouring keys in the same row (x, c and v). For instance, all find commands are placed sequentially in the same row (f, g, h, j and k). All save commands are placed in neighbouring keys (s, e and r). The dedent and indent events are moved to the same row as 4 other events that affect a region, like comment and uncomment (numeric keys row, 1 to 9), along with some other events associated with tabs. Finally, 2 of the most used virtual events, <> and <>, are now bound to and , which should be much more obvious than and . The old bindings are hard to understand unless you have a history of Emacs ab^H^Huse, and are not as intuitive as using the arrows with a modifier key. Extension bindings ------------------ The key bindings for virtual events belonging to IDLE extensions are currently defined in config-extensions.def and are not customizable directly from IDLE. Since 4 of these virtual events currently use the Alt modifier, they conflict with the above rationale of using one single modifier key for all shortcuts, viz. the Control key. I propose to expand these currents shortcuts with another key bindings that fits in with the proposed [IDLE Modern] scheme: format-paragraph= expand-word= zoom-height= run-module= # unchanged check-module= Binding changes --------------- Comparison of [IDLE Modern] bindings to [IDLE Classic Windows] bindings: a) Identical bindings: beginning-of-line= close-all-windows= # modifier-q is a standard binding for 'quit' in Mac (increasingly used in Windows) copy= # modifier-c is a standard binding 'copy' in Windows and Mac cut= # modifier-x is a standard binding 'cut' in Windows and Mac do-nothing= end-of-file= find= # modifier-f is a standard binding for 'find' in Windows and Mac newline-and-indent= open-new-window= # modifier-n is a standard binding for 'new' in Windows and Mac open-window-from-file= # modifier-o is a standard binding for 'open' in Windows and Mac paste= # modifier-v is a standard binding for 'paste' in Windows and Mac print-window= # modifier-p is a standard binding for 'print' in Windows and Mac python-docs= remove-selection= replace= # modifier-h is a standard binding for 'replace' in Windows and Mac save-window= # modifier-s is a standard binding for 'save' in Windows and Mac select-all= # modifier-a is a standard binding for 'select-all' in Windows and Mac smart-backspace= smart-indent= undo= # modifier-z is a standard binding for 'undo' in Windows and Mac view-restart= b) Similar bindings (Alt or Meta modifier replaced with Control modifier): comment-region= open-module= uncomment-region= tabify-region= untabify-region= c) Changed bindings: center-insert= change-indentwidth= close-window= # modifier-w is a standard binding for 'close-window' in Mac (increasingly used in Windows) dedent-region= find-again= # modifier-g is a standard binding for 'find-again' in Windows and Mac find-in-files= find-selection= goto-line= # modifier-l is a common but not standard binding for 'goto-line' in Windows and Mac history-next= history-previous= indent-region= interrupt-execution= open-class-browser= plain-newline-and-indent= python-context-help= redo= # modifier-y is a common but not standard binding for 'redo' in Windows and Mac restart-shell= save-copy-of-window-as-file= save-window-as-file= toggle-auto-coloring= toggle-tabs= Bindings ordered by key ----------------------- smart-backspace= remove-selection= beginning-of-line= newline-and-indent= smart-indent= python-docs= view-restart= restart-shell= python-context-help= do-nothing= history-previous= history-next= dedent-region= indent-region= comment-region= uncomment-region= tabify-region= untabify-region= change-indentwidth= toggle-tabs= toggle-auto-coloring= select-all= open-class-browser= copy= end-of-file= save-window-as-file= find= find-again= replace= interrupt-execution= find-selection= find-in-files= goto-line= open-module= open-new-window= open-window-from-file= print-window= close-all-windows= save-copy-of-window-as-file= save-window= center-insert= plain-newline-and-indent= paste= close-window= cut= redo= undo= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-12 15:10 Message: Logged In: YES user_id=819035 Thanks for the instructive comments. Here are some answers: 1) The problems are the following: a) The standard key bindings are the IDLE Classic Windows key bindings, which do not work. - None of the many bindings that use the Alt modifier work, since the Alt (a.k.a. Option) key is used in MacOSX for accents and symbols. b) The IDLE Classic Mac key bindings do not work. - Most of them require the Command key, which for some unknown reason do not seem to work. c) The IDLE Classic Unix key bindings mostly work, but are unsatisfactory. - These bindings replace many "chord" key bindings with emacs style shortcuts, which are frankly unpleasant to use for 99% of people not used to emacs. Also, there are still several of these Unix key bindings that use the Alt modifier, and which thus do not work in MacOSX. In spite of all this, it is the most usable of the 3 default schemes. d) 5 key bindings used by extensions are currently not rebindable: Alt-Key-q, Alt-Key-slash, Alt-Key-2, Alt-Key-x and Key-F5. Since 4 of them use the Alt modifier, they do not work under MacOSX e) Some bits of extend.txt and help.txt are outdated. 2) A slightly awkward workaround to problem 1.b: What I meant was that by replacing Command with Meta in key bindings means that many but far from all Command bindings work. By chance, I discovered that using the Control-Command combination instead of just the Command modifier makes most if not all Meta bindings work. It seems as if Meta really is interpreted as Control-Command, with Command working sometimes. This is not very satisfactory, but it's better than any of the other 3 default bindings. 3) Regarding capitalization: I discovered by accident that Tk keybindings are case sensitive. However, all bindings mentioned by me treat capitals and lowercase letters identically, i.e. when I wrote Command-B, I really meant Command-b, and not Command-Shift-b. I'll take care not make that confusion from now on. 4) Command-b and Control-b: The bindings mentioned in my 2003-07-11 18:48 message are Command bindings. Command-b and Command-f really do move to the beginning and end of words, unlike Control-b and Control-f, which move one character back and one character forward. I have no idea why some these Command bindings work, but the fact is they do. 5) It might be useful to get other MacOSX users to check my findings, since there might quirks with my configuration which I'm not aware of. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 16:43 Message: Logged In: YES user_id=149084 Thank you for reporting the issues with help.txt and extend.txt. I will update these files. You are correct about the renaming, extend.txt has not been updated since the new config system was implemented. I agree it would be nice to set the extension configuration from the configuration dialog. However, we are much too close to release to contemplate doing that for 2.3. The extension feature is intended to incorporate 3rd party features so the enhancement of the config dialog would have to be suitably general. Your problem appears to be down to one thing: none of IDLE's "Classic Mac" Command combinations in your config-keys.def work. If I understand you correctly, you are saying that e.g. replacing "Command-Key-w" by "Meta-Key-w" in config-keys.def causes the <> event to work correctly? Note that Tk is very picky about capitalization. "Command-Key-w" is not the same as "Command-Key-W". Please be sure that your file is correct in this regard. If you can get everything working by doing this, would you please upload the modified version of your config-keys.def and let me know what the remaining problems are, if any. In your messages you have variously said that both "Command-B" and "Ctl-b" keystrokes go to the beginning of a word. Is this correct? And do you really mean "Apple/Shift/b" in the first case? The Ctl-b binding and others like it that you have mentioned in your earlier message are part of a number of default Tk bindings that have not been disabled in IDLE. http://www.tcl.tk/man/tcl8.3/TkCmd/text.htm#M141 Clearly, there may not be complete compatibility with this documentation in the Tk Mac implementation. But that is the origin of the bindings. By the way, the way to customize is not to modify config-keys.def, but to modify your .idlerc/config-keys.cfg or any of the other files in that directory. That is what the config dialog does, and it is quite all right to modify it manually as long as you carefully follow the format. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 15:08 Message: Logged In: YES user_id=819035 The file extend.txt references two files that do not exist: keydefs and config.txt I suppose the former corresponds config-keys.def, while the latter has been split into 3 files: config-main.def, config-extensions.def and config-highlight.def. Is this correct? Looking into config-extensions.def, I can finally see were those non-standard key sequences are defined: [FormatParagraph_cfgBindings] format-paragraph= (...) [AutoExpand_cfgBindings] expand-word= (...) [ZoomHeight_cfgBindings] zoom-height= (...) [ScriptBinding_cfgBindings] run-module= check-module= It would nice if these key bindings for extension modules could be put in the same file as the standard key bindings. Even nicer if the configuration dialog could be used to change all key bindings. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 14:48 Message: Logged In: YES user_id=819035 Using the original [IDLE Classic Mac] shortcut keys definitions, the only Command shortcuts that do anything are the following: Command-Q: tries to quit X11 instead of IDLE Command-W: closes X11 windows instead of IDLE windows Command-B: go to beginning of word Command-F: go to end of word Command-D: delete next word Command-H: hide X11 Command-M: minimize window Command-,: X11 preferences dialog ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 14:43 Message: Logged In: YES user_id=819035 Sorry, my confusion. Since I edited my original config-keys.def file, I forgot that the [IDLE Classic Mac] shortcuts used the Command modifier, and not Alt. This confusion is only made in my last message. If you replace "Command" with "Alt" in that message, everything makes sense: """ If I change all keybinding using the Command-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Command, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. """ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 14:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 12:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 12:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 15:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 15:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 12:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 09:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 01:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Tue Jul 29 04:23:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 20:23:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http Message-ID: Bugs item #767111, was opened at 2003-07-07 08:52 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Stuart Bishop (zenzen) Assigned to: Nobody/Anonymous (nobody) Summary: AttributeError thrown by urllib.open_http Initial Comment: In 2.3b2, looks like an error condition isn't being picked up on line 300 or 301 of urllib.py. The code that triggered this traceback was simply: url = urllib.urlopen(action, data) Traceback (most recent call last): File "autospamrep.py", line 170, in ? current_page = handle_spamcop_page(current_page) File "autospamrep.py", line 140, in handle_spamcop_page url = urllib.urlopen(action, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 78, in urlopen return opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 183, in open return getattr(self, name)(url, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 308, in open_http return self.http_error(url, fp, errcode, errmsg, headers, data) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 323, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 551, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 837, in __init__ addbase.__init__(self, fp) File "/Library/Frameworks/Python.framework/Versions/2.3/ lib/python2.3/urllib.py", line 787, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 23:23 Message: Logged In: YES user_id=12800 Please provide a self-contained, complete example that we can use to reproduce this problem. Without enough information, I can't see us fixing this for Python 2.3, and time for that is rapidly running out. Lowering to priority 6. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2003-07-17 00:34 Message: Logged In: YES user_id=46639 I've finally managed to get another traceback with some more information, using an assert I inserted into urllib.py a while ago to catch .fp == None: Traceback (most recent call last): File "/Users/zen/bin/autospamrep.py", line 168, in ? current_page = urllib.urlopen(start_url).read() File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 76, in urlopen return opener.open(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 181, in open return getattr(self, name)(url) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/urllib.py", line 305, in open_http assert fp is not None, 'errcode %r, errmsg %r, headers %r' % (errcode, errmsg, headers) AssertionError: errcode -1, errmsg '', headers None ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2003-07-12 09:14 Message: Logged In: YES user_id=261020 HTTPResponse.read returns '' if its .fp is None, but the backwards-compat HTTP class' .getfile() just returns self.file, which it previously grabbed from HTTPResponse in .getreply(). Wild guess: maybe HTTP.getreply should just do self.file = response rather than self.file = response.fp The object returned by HTTP.getfile() was documented as returning an object supporting .readline() and .readlines(), while HTTPResponse only supports .read(), so that's obviously not the whole solution. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 01:50 Message: Logged In: YES user_id=80475 What were the values of 'action' and 'data' when the call was made? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470 From noreply@sourceforge.net Tue Jul 29 04:38:01 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 20:38:01 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 08:35 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 23:38 Message: Logged In: YES user_id=12800 I'm not sure there's anything we can do about this for Python 2.3 final. Lowering the priority, although I will add a note in known bugs.html page. ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2003-07-27 19:04 Message: Logged In: YES user_id=827666 Hi. I just thought I'd mention that I got the same results with 2.3c2. Tim ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2003-07-21 23:09 Message: Logged In: YES user_id=827666 Hello. I just downloaded 2.3c1. I failed test_time as well. I was going to submit a new bug, but then I saw this thread. I hope this is the right place. test_time test test_time failed -- Traceback (most recent call last): File "/home/tim/Download/Python-2.3c1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/tim/Download/Python-2.3c1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST 227 tests OK. 1 test failed: test_time 27 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_email_codecs test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on linux2. make: *** [test] Error 1 For what it's worth, time seems to work... $ ./python -c 'import time; print time.tzname' ('EST', 'EDT') $ cat /proc/version Linux version 2.4.20 (root@mrbun) (gcc version 2.95.3 20010315 (release)) #11 Sat Nov 30 05:52:58 EST 2002 Tim ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-12 22:28 Message: Logged In: YES user_id=357491 I uploaded a new version of the patch. Give it a try and see what happens if you could. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-10 13:11 Message: Logged In: YES user_id=357491 Barry says you need to do the following to truly test the patch: - check out the head - make distclean - apply the patch - autoreconf - ./configure --with-pydebug - make test Apparently autoreconf regenerates something for autoconf and that has to be done. Learn something new everyday. Can you give that a shot, Torsten? If that still fails it is going to take some work to figure this one out. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-10 03:58 Message: Logged In: YES user_id=269193 no, sorry, no success! * re-compiled python, as expected the test failed again. * patch -p0 <../tzset4.diff * made a "make distclean" * ./configure again, looked nice, no chached stuff. * make * make test >>> failed again !!! anything i could check to help? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-10 00:37 Message: Logged In: YES user_id=80475 Tonight, test_time also failed for me and then worked on the next pass. Am using WinME and Py2.3b2+. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-09 14:30 Message: Logged In: YES user_id=269193 sorry, problem! hard drive scambled. i have to re-install python anyway. i will see if the test fails again, and then i try to apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 13:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 01:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 22:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 13:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 11:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Tue Jul 29 04:59:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 20:59:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-743692 ] test_socketserver: Fatal error: Invalid thread state Message-ID: Bugs item #743692, was opened at 2003-05-26 10:30 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743692&group_id=5470 Category: Threads Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Mark Hammond (mhammond) Summary: test_socketserver: Fatal error: Invalid thread state Initial Comment: Mark, I believe this started happening on Solaris 8 (only AFAIK) after some of your thread changes. Do you have access to a Solaris 8 box? I can try to debug if you give me some ideas. This is happening on the snake farm. Actually, we have a Sol8 box here. I can try to fire it up and see if the problem exists on that box. If so, I can give you access. When running test_socketserver, some way through the test there's the fatal error. Fatal Python error: Invalid thread state for this thread Let me know what more info I can provide. Sorry, short on ideas/time, just wanted to get this documented. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 23:59 Message: Logged In: YES user_id=12800 What can we do about this for 2.3 final? Probably nothing given the deadline. Lowering the priority. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-10 00:25 Message: Logged In: YES user_id=33168 I changed the DELAY in the test to be zero. The test fails, but it's interesting that it also hangs in lock_PyThread_acquire_lock (line 63): Lib/threading.py (195): wait Lib/threading.py (468): join Lib/threading.py (564): __exitfunc Lib/atexit.py (11): _run_exitfuncs In looking at threadmodule.c I notice that most of the time Py_BEGIN_ALLOW_THREADS/Py_END_ALLOW_THREADS is not used around PyThread_acquire_lock, but it is in lock_PyThread_acquire_lock. I'm not sure all of these are safe. Here's some more detail on the Sun: test_socketserver ADDR = ('localhost', 17231) CLASS = SocketServer.ForkingTCPServer server created thread: creating server server running thread: serving three times test client 0 Fatal Python error: Invalid thread state for this thread ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-10 00:08 Message: Logged In: YES user_id=33168 Doesn't seem real helpful. I'll see if I can do more on this. #0 PyThreadState_Swap (new=0x2b1160) at Python/pystate.c:274 #1 PyEval_RestoreThread (tstate=0x2b1160) at Python/ceval.c:391 #2 floatsleep (secs=0) at Modules/timemodule.c:831 #3 time_sleep (self=0x0, args=0x2b3968) at Modules/timemodule.c:208 #4 PyCFunction_Call (func=0x2bd938, arg=0x2b3968, kw=0x0) at Objects/methodobject.c:73 #5 call_function (pp_stack=0xdf142f04, oparg=1) at Python/ceval.c:3439 #6 eval_frame (f=0x2890c8) at Python/ceval.c:2116 ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-08 00:39 Message: Logged In: YES user_id=14198 I don't have access to a sol8 box, nor would I really know what to do when I got there :) Any chance of a stack-trace? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743692&group_id=5470 From noreply@sourceforge.net Tue Jul 29 05:08:11 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 21:08:11 -0700 Subject: [Python-bugs-list] [ python-Bugs-775985 ] Solaris error doing a print Message-ID: Bugs item #775985, was opened at 2003-07-22 17:18 Message generated for change (Comment added) made by hobbs You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris error doing a print Initial Comment: As seen on Jeff Hobb's box. print "Registering '%s' (%s)" % (reg_contractid, fname) File "/usr/local/python-2.3/lib/python2.3/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) ValueError: Empty module name It seems that this shell has an empty "LANG" var setup - deleting this var seems to solve the problem. Looking in sysmodule.c, I see: if(codeset && isatty(fileno(stdin))){ (and a similar one for stdout). Should this be: if(codeset && *codeset && isatty(fileno(stdin))){ to prevent an empty name? Or better, should we check the encoding is actually installed? I will mail Jeff and ask him to attach comments on the version or anything else. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-28 21:08 Message: Logged In: YES user_id=72656 I think you have to unset LANG rather than set to "", but I'm not really understanding this one, so I defer to Mark. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 20:15 Message: Logged In: YES user_id=12800 Before I can comment on this for 2.3 (and time is very quickly running out), can you provide: 1. a recipe to reproduce this on RH9 or other Linux? I tried in bash: % export LANG="" % ./python >>> print "foo" foo >>> i.e. nothing happened, so I'm sure I'm not doing this right. Also, any possibility of a test case? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-22 22:16 Message: Logged In: YES user_id=21627 I'm tempted to declare this a platform bug: Both Linux and later Solaris versions set the CODEPAGE to ASCII for an empty LANG (i.e. assume this is the "C" locale). Still, checking whether the encoding is present is probably a good idea. Unfortunately, it cannot be done right there, since loading of codecs does not work yet inside _PySys_Init. So as a work-around for 2.3, we should check for non-empty strings, and leave checking for supported encodings for 2.3.1. Patch attached. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-22 17:26 Message: Logged In: YES user_id=72656 python 2.3rc1, build --enable-shared. Solaris uname -a: SunOS knife 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra- 250 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 From noreply@sourceforge.net Tue Jul 29 05:31:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 21:31:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-778964 ] parameter confusion in 2.3c2 Message-ID: Bugs item #778964, was opened at 2003-07-28 21:47 Message generated for change (Comment added) made by blaforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) Summary: parameter confusion in 2.3c2 Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Bill la Forge (blaforge) Date: 2003-07-29 11:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 10:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 22:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply@sourceforge.net Tue Jul 29 05:35:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 21:35:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-775985 ] Solaris error doing a print Message-ID: Bugs item #775985, was opened at 2003-07-23 02:18 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 7 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris error doing a print Initial Comment: As seen on Jeff Hobb's box. print "Registering '%s' (%s)" % (reg_contractid, fname) File "/usr/local/python-2.3/lib/python2.3/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) ValueError: Empty module name It seems that this shell has an empty "LANG" var setup - deleting this var seems to solve the problem. Looking in sysmodule.c, I see: if(codeset && isatty(fileno(stdin))){ (and a similar one for stdout). Should this be: if(codeset && *codeset && isatty(fileno(stdin))){ to prevent an empty name? Or better, should we check the encoding is actually installed? I will mail Jeff and ask him to attach comments on the version or anything else. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-29 06:35 Message: Logged In: YES user_id=21627 This is not reproducable on Linux. nl_langinfo(CODESET) will always give a non-empty string. If LANG is not set, the user thereby requests the "POSIX" locale, and its codeset is ANSI_X3.4-1968. So it *is* a bug in that Solaris version that it returns an empty string; the empty string is a valid return value only if the argument to nl_langinfo was invalid. Since the system does support querying the CODESET in principle, it should not be possible to ever get an empty string. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-29 06:08 Message: Logged In: YES user_id=72656 I think you have to unset LANG rather than set to "", but I'm not really understanding this one, so I defer to Mark. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 05:15 Message: Logged In: YES user_id=12800 Before I can comment on this for 2.3 (and time is very quickly running out), can you provide: 1. a recipe to reproduce this on RH9 or other Linux? I tried in bash: % export LANG="" % ./python >>> print "foo" foo >>> i.e. nothing happened, so I'm sure I'm not doing this right. Also, any possibility of a test case? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-23 07:16 Message: Logged In: YES user_id=21627 I'm tempted to declare this a platform bug: Both Linux and later Solaris versions set the CODEPAGE to ASCII for an empty LANG (i.e. assume this is the "C" locale). Still, checking whether the encoding is present is probably a good idea. Unfortunately, it cannot be done right there, since loading of codecs does not work yet inside _PySys_Init. So as a work-around for 2.3, we should check for non-empty strings, and leave checking for supported encodings for 2.3.1. Patch attached. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-23 02:26 Message: Logged In: YES user_id=72656 python 2.3rc1, build --enable-shared. Solaris uname -a: SunOS knife 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra- 250 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 From noreply@sourceforge.net Tue Jul 29 05:39:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 21:39:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-778964 ] parameter confusion in 2.3c2 Message-ID: Bugs item #778964, was opened at 2003-07-28 10:47 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) Summary: parameter confusion in 2.3c2 Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 00:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 00:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-28 23:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 11:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply@sourceforge.net Tue Jul 29 05:42:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 21:42:04 -0700 Subject: [Python-bugs-list] [ python-Bugs-775985 ] Solaris error doing a print Message-ID: Bugs item #775985, was opened at 2003-07-22 20:18 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris error doing a print Initial Comment: As seen on Jeff Hobb's box. print "Registering '%s' (%s)" % (reg_contractid, fname) File "/usr/local/python-2.3/lib/python2.3/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) ValueError: Empty module name It seems that this shell has an empty "LANG" var setup - deleting this var seems to solve the problem. Looking in sysmodule.c, I see: if(codeset && isatty(fileno(stdin))){ (and a similar one for stdout). Should this be: if(codeset && *codeset && isatty(fileno(stdin))){ to prevent an empty name? Or better, should we check the encoding is actually installed? I will mail Jeff and ask him to attach comments on the version or anything else. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 00:42 Message: Logged In: YES user_id=12800 I'm taking this to mean that there's nothing showstopping for Python 2.3 final here. If we want to implement the workaround for the Solaris bug in 2.3.1, then we can do that when we have some breathing room. Lowering the priority. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-29 00:35 Message: Logged In: YES user_id=21627 This is not reproducable on Linux. nl_langinfo(CODESET) will always give a non-empty string. If LANG is not set, the user thereby requests the "POSIX" locale, and its codeset is ANSI_X3.4-1968. So it *is* a bug in that Solaris version that it returns an empty string; the empty string is a valid return value only if the argument to nl_langinfo was invalid. Since the system does support querying the CODESET in principle, it should not be possible to ever get an empty string. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-29 00:08 Message: Logged In: YES user_id=72656 I think you have to unset LANG rather than set to "", but I'm not really understanding this one, so I defer to Mark. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 23:15 Message: Logged In: YES user_id=12800 Before I can comment on this for 2.3 (and time is very quickly running out), can you provide: 1. a recipe to reproduce this on RH9 or other Linux? I tried in bash: % export LANG="" % ./python >>> print "foo" foo >>> i.e. nothing happened, so I'm sure I'm not doing this right. Also, any possibility of a test case? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-23 01:16 Message: Logged In: YES user_id=21627 I'm tempted to declare this a platform bug: Both Linux and later Solaris versions set the CODEPAGE to ASCII for an empty LANG (i.e. assume this is the "C" locale). Still, checking whether the encoding is present is probably a good idea. Unfortunately, it cannot be done right there, since loading of codecs does not work yet inside _PySys_Init. So as a work-around for 2.3, we should check for non-empty strings, and leave checking for supported encodings for 2.3.1. Patch attached. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-22 20:26 Message: Logged In: YES user_id=72656 python 2.3rc1, build --enable-shared. Solaris uname -a: SunOS knife 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra- 250 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 From noreply@sourceforge.net Tue Jul 29 05:49:00 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 21:49:00 -0700 Subject: [Python-bugs-list] [ python-Bugs-775985 ] Solaris error doing a print Message-ID: Bugs item #775985, was opened at 2003-07-23 10:18 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 7 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris error doing a print Initial Comment: As seen on Jeff Hobb's box. print "Registering '%s' (%s)" % (reg_contractid, fname) File "/usr/local/python-2.3/lib/python2.3/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) ValueError: Empty module name It seems that this shell has an empty "LANG" var setup - deleting this var seems to solve the problem. Looking in sysmodule.c, I see: if(codeset && isatty(fileno(stdin))){ (and a similar one for stdout). Should this be: if(codeset && *codeset && isatty(fileno(stdin))){ to prevent an empty name? Or better, should we check the encoding is actually installed? I will mail Jeff and ask him to attach comments on the version or anything else. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-29 14:49 Message: Logged In: YES user_id=29957 I can't reproduce this on Solaris 2.6 (x86 version). $ env LANG="" ./python Python 2.3 (#1, Jul 29 2003, 04:41:38) [GCC egcs-2.91.57 19980901 (egcs-1.1 release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> print "hello world" hello world >>> ^D $ uname -a SunOS star 5.6 Generic_105182-05 i86pc i386 i86pc I also tried unsetting LANG, setting it to the empty string, to a single space, and was unable to get any problems to show. It also doesn't show on Solaris 2.7 (sparc) - I no longer have any sparcs running 2.6. I'd say it's safe to lower the priority and miss this one for 2.3. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 14:42 Message: Logged In: YES user_id=12800 I'm taking this to mean that there's nothing showstopping for Python 2.3 final here. If we want to implement the workaround for the Solaris bug in 2.3.1, then we can do that when we have some breathing room. Lowering the priority. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-29 14:35 Message: Logged In: YES user_id=21627 This is not reproducable on Linux. nl_langinfo(CODESET) will always give a non-empty string. If LANG is not set, the user thereby requests the "POSIX" locale, and its codeset is ANSI_X3.4-1968. So it *is* a bug in that Solaris version that it returns an empty string; the empty string is a valid return value only if the argument to nl_langinfo was invalid. Since the system does support querying the CODESET in principle, it should not be possible to ever get an empty string. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-29 14:08 Message: Logged In: YES user_id=72656 I think you have to unset LANG rather than set to "", but I'm not really understanding this one, so I defer to Mark. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 13:15 Message: Logged In: YES user_id=12800 Before I can comment on this for 2.3 (and time is very quickly running out), can you provide: 1. a recipe to reproduce this on RH9 or other Linux? I tried in bash: % export LANG="" % ./python >>> print "foo" foo >>> i.e. nothing happened, so I'm sure I'm not doing this right. Also, any possibility of a test case? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-23 15:16 Message: Logged In: YES user_id=21627 I'm tempted to declare this a platform bug: Both Linux and later Solaris versions set the CODEPAGE to ASCII for an empty LANG (i.e. assume this is the "C" locale). Still, checking whether the encoding is present is probably a good idea. Unfortunately, it cannot be done right there, since loading of codecs does not work yet inside _PySys_Init. So as a work-around for 2.3, we should check for non-empty strings, and leave checking for supported encodings for 2.3.1. Patch attached. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-23 10:26 Message: Logged In: YES user_id=72656 python 2.3rc1, build --enable-shared. Solaris uname -a: SunOS knife 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra- 250 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 From noreply@sourceforge.net Tue Jul 29 06:07:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 22:07:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-775985 ] Solaris error doing a print Message-ID: Bugs item #775985, was opened at 2003-07-23 10:18 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None >Priority: 6 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Solaris error doing a print Initial Comment: As seen on Jeff Hobb's box. print "Registering '%s' (%s)" % (reg_contractid, fname) File "/usr/local/python-2.3/lib/python2.3/encodings/__init__.py", line 84, in search_function globals(), locals(), _import_tail) ValueError: Empty module name It seems that this shell has an empty "LANG" var setup - deleting this var seems to solve the problem. Looking in sysmodule.c, I see: if(codeset && isatty(fileno(stdin))){ (and a similar one for stdout). Should this be: if(codeset && *codeset && isatty(fileno(stdin))){ to prevent an empty name? Or better, should we check the encoding is actually installed? I will mail Jeff and ask him to attach comments on the version or anything else. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-29 15:07 Message: Logged In: YES user_id=29957 woops. I accidently reset the priority (overlapping commit) ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2003-07-29 14:49 Message: Logged In: YES user_id=29957 I can't reproduce this on Solaris 2.6 (x86 version). $ env LANG="" ./python Python 2.3 (#1, Jul 29 2003, 04:41:38) [GCC egcs-2.91.57 19980901 (egcs-1.1 release)] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> print "hello world" hello world >>> ^D $ uname -a SunOS star 5.6 Generic_105182-05 i86pc i386 i86pc I also tried unsetting LANG, setting it to the empty string, to a single space, and was unable to get any problems to show. It also doesn't show on Solaris 2.7 (sparc) - I no longer have any sparcs running 2.6. I'd say it's safe to lower the priority and miss this one for 2.3. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 14:42 Message: Logged In: YES user_id=12800 I'm taking this to mean that there's nothing showstopping for Python 2.3 final here. If we want to implement the workaround for the Solaris bug in 2.3.1, then we can do that when we have some breathing room. Lowering the priority. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-29 14:35 Message: Logged In: YES user_id=21627 This is not reproducable on Linux. nl_langinfo(CODESET) will always give a non-empty string. If LANG is not set, the user thereby requests the "POSIX" locale, and its codeset is ANSI_X3.4-1968. So it *is* a bug in that Solaris version that it returns an empty string; the empty string is a valid return value only if the argument to nl_langinfo was invalid. Since the system does support querying the CODESET in principle, it should not be possible to ever get an empty string. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-29 14:08 Message: Logged In: YES user_id=72656 I think you have to unset LANG rather than set to "", but I'm not really understanding this one, so I defer to Mark. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 13:15 Message: Logged In: YES user_id=12800 Before I can comment on this for 2.3 (and time is very quickly running out), can you provide: 1. a recipe to reproduce this on RH9 or other Linux? I tried in bash: % export LANG="" % ./python >>> print "foo" foo >>> i.e. nothing happened, so I'm sure I'm not doing this right. Also, any possibility of a test case? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-23 15:16 Message: Logged In: YES user_id=21627 I'm tempted to declare this a platform bug: Both Linux and later Solaris versions set the CODEPAGE to ASCII for an empty LANG (i.e. assume this is the "C" locale). Still, checking whether the encoding is present is probably a good idea. Unfortunately, it cannot be done right there, since loading of codecs does not work yet inside _PySys_Init. So as a work-around for 2.3, we should check for non-empty strings, and leave checking for supported encodings for 2.3.1. Patch attached. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2003-07-23 10:26 Message: Logged In: YES user_id=72656 python 2.3rc1, build --enable-shared. Solaris uname -a: SunOS knife 5.6 Generic_105181-05 sun4u sparc SUNW,Ultra- 250 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775985&group_id=5470 From noreply@sourceforge.net Tue Jul 29 06:10:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 22:10:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-778400 ] IDLE hangs when selecting "Edit with IDLE" from explorer Message-ID: Bugs item #778400, was opened at 2003-07-27 04:32 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778400&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) >Assigned to: Tim Peters (tim_one) Summary: IDLE hangs when selecting "Edit with IDLE" from explorer Initial Comment: IDLE editor window hangs when right clicking a file and selecting "Edit with IDLE" Steps to reproduce: o Open IDLE o Open explorer o Right click on a .py file o Choose "Edit with IDLE" A new IDLE edit window opens but it is not responding. The original (shell) IDLE window works fine. If you do the above without opening an IDLE shell it works fine. My system is win2k on IBM T30 (LapTop). ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-29 00:10 Message: Logged In: YES user_id=149084 Sorry, I should have used the -n switch the first time. Hopefully this can be 2.3. Currently on Windows IDLE can partially start multiple instances under conditions still not fully understood. The comment by tebeka is interesting but not a universal fix, I believe. If IDLE is configured to open a shell (the default) it will exhibit this behaviour. If configured to open an edit window at startup, it won't. The -n switch causes IDLE to not use the subprocess, so it acts like the old IDLE and mutliple copies are not a problem. I'm increasingly inclined to think that the -e switch should act like an "editor window on startup" configuration, since opening multiple shells is ugly when configured to "open shell on startup." Eventually it will be possible to run multiple IDLE instances, each with its own subprocess, but that's 2.4. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-28 02:10 Message: Logged In: YES user_id=358087 When I change idle.pyw from from idlelib.PyShell import main to import idlelib.PyShell idlelib.PyShell.main() I get a responsive IDLE edit window + a new shell window. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-27 11:53 Message: Logged In: YES user_id=31435 Assigned to Kurt. On Win2K the steps above don't create a problem for me, but I get a frozen window if I repeat the last two steps. The whole failing sequence for me on a Win2K desktop box: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" o Right click on another .py file o Choose "Edit with IDLE" On Win98SE, the first "Edit with IDLE" works fine. The second "Edit with IDLE" opens a new shell window but not a window for the selected .py file. Third and subsequent "Edit with IDLE" steps have no visible effect (neither a new shell nor a new edit window open). Something is left in a hosed state then: if I close all the open IDLE windows, and try "Edit with IDLE" again, nothing visible happens. The Win98SE task manager (Ctrl+Alt+Del) doesn't show any Python processes running at that point, and neither does WinTop. It's still possible to start another IDLE, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778400&group_id=5470 From noreply@sourceforge.net Tue Jul 29 06:16:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 28 Jul 2003 22:16:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-768469 ] IDLE/MAC: Command / Alt Bindings Don't Work Message-ID: Bugs item #768469, was opened at 2003-07-09 08:49 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Rejected >Priority: 3 Submitted By: Tiago Castro Henriques (tiagoh) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE/MAC: Command / Alt Bindings Don't Work Initial Comment: I'm running IDLE under MacOSX 10.2.6 using Python 2.3b2. Using Apple's X11 beta 3 version, I am unable to access any of the shortcuts that use the Alt key, including the history keystrokes that recall past commands. In my configuration at least, the Alt key is being used (as usual) to access special characters and accented characters. Is there any way to bypass this, allowing the Alt key to be handled directly by IDLE? ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-29 00:16 Message: Logged In: YES user_id=149084 Closing as not a Python issue. Please feel free to re-open if there is something further to discuss. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 22:20 Message: Logged In: YES user_id=12800 Is there something that I need to decide on for Python 2.3 final? Realize that time has nearly run out so only absolutely critical fixes (or documentation changes) can go in. I'm lowering the priority since there doesn't seem to be anything critical for 2.3 final. If you disagree, please raise priority back to 7 and describe exactly what you'd like for me to decide on. ---------------------------------------------------------------------- Comment By: Tony Lownds (tonylownds) Date: 2003-07-16 10:49 Message: Logged In: YES user_id=24100 [tiagoh] >Using Apple's X11 beta 3 version, I am unable to access >any of the shortcuts that use the Alt key, including >the history keystrokes that recall past commands. >... >Is there any way to bypass this, allowing the Alt key >to be handled directly by IDLE? So, IDLE is running under X11? Perhaps you can bypass the undesirable behavior by changing the configuration of the X11 server. IDLE can not do anything to help in your situation, AFAIK, as it is X11 that is not giving the keystrokes to Tk. Have you tried using the native-windowing- system version of Tk, instead of Tk through X11? Mac keys bindings work smoothly, you can even override bindings if you like. [tiagoh again] >Unless I'm doing something stupid, this would be a serious >defect with respect to IDLE usability under MacOSX It is a serious defect to usability with respect to IDLE usability under MacOSX *under X11*. That is a big difference. Perhaps some information about using native Tk instead of through X11 would be good to add. Unless I am missing something about your software setup. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-15 22:14 Message: Logged In: YES user_id=149084 Lib/idlelib: Updated extend.txt (Rev 1.4), help.txt (Rev 1.10), and config-extensions.def (Rev 1.12) to partially correct the issues this bug raised. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-14 20:36 Message: Logged In: YES user_id=149084 I'd like to focus on the bug rather than an RFE for a new keyset. I'd suggest that you use [IDLE Modern] for a couple of months and then post your suggestion to the Idle-dev email list for comment. Please note that the Shift modifier isn't working because there is a bug (already reported on the IDLEfork Tracker). I have asked the IDLEfork Mac expert to take a look at this bug, which is that the Command-[something] bindings don't work (unless they happen to be default Tk bindings). There is also an issue with the use of Alt keys in the extensions. Originally, IDLE had the ability to define extension keybindings for each platform. These were eliminated in IDLEfork with, I believe, the intention to expand the configuration dialog to replace them. However, that has not as yet been accomplished. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 15:39 Message: Logged In: YES user_id=819035 File attachment doesn't seem to be working for me using Mozilla Firebird. Here is the tentative [IDLE Modern] key binding scheme, ordered by virtual event name: [IDLE Modern] beginning-of-line= center-insert= change-indentwidth= close-all-windows= close-window= comment-region= copy= cut= dedent-region= do-nothing= end-of-file= find-again= find-in-files= find-selection= find= goto-line= history-next= history-previous= indent-region= interrupt-execution= newline-and-indent= open-class-browser= open-module= open-new-window= open-window-from-file= paste= plain-newline-and-indent= print-window= python-context-help= python-docs= redo= remove-selection= replace= restart-shell= save-copy-of-window-as-file= save-window-as-file= save-window= select-all= smart-backspace= smart-indent= tabify-region= toggle-auto-coloring= toggle-tabs= uncomment-region= undo= untabify-region= view-restart= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-14 15:28 Message: Logged In: YES user_id=819035 Proposal for new key binding scheme =================================== Problem ------- Due to several reasons discussed in my previous messages, the 3 available key binding schemes for IDLE in MacOSX are not satisfactory for various reasons, the main one being that the Alt/Option modifier is preempted by MacOSX for accented characters and symbols, and the Command/Apple modifier is preempted by X11 for several shortcuts. Considering that IDLE is supposed to be a tool for beginners as well as for more advanced programmers, the key binding scheme for Windows (which is currently the default scheme) also has a few problems. Although all shortcuts in the [IDLE Classic Windows] key binding scheme seem to work, they use an inconsistent mix of modifier keys that hinders learning and makes it difficult to use in platforms where modifier keys work differently. Most of these shortcuts use the Control and Alt modifiers, but some shortcuts use 2 or more modifiers or a third modifier: Control modifier: close-all-windows= Alt/Meta modifier: close-window= Shift modifier: python-context-help= Several modifiers: redo= save-copy-of-window-as-file= Proposal -------- I propose to use a new key binding scheme that uses one single modifier key for all shortcuts in order to increase learnability and portability. The Control modifier is the natural choice for the standard modifier, since unlike the Alt, Command or Windows modifiers it is not usually used for standard OS shortcuts. I am attaching to this message my ~/.idlerc/config-keys.cfg file containing the bindings for this scheme, which I have tentatively named [IDLE Modern]. My hope is to have this scheme become one of the additional schemes shipped with IDLE, and perhaps even replace the [IDLE Classic Windows] scheme as the default scheme for IDLE on all platforms. Rationale --------- I tried to preserve most bindings that have become common in Mac, Windows and Linux applications, and change non-standard bindings to standard. I have also changed all bindings that use a modifier different from Control, sometimes using a similar binding (e.g. instead of for the <> virtual event), sometimes using a completely different binding. I strived to use only alphabetical keys, numerical keys and function keys, since other characters tend to shift according to which keyboard layout one is using. For instance, in the Portuguese keyboard layout the bracket characters have to accessed using a special modifier key, labeled AltGr (for Alt Graphics) together with a numeric key (AltGr-Key-7 and AltGr-Key-8), while the slash character has to be written using Shift-Key-7. This means that the standard bindings for the <>, <> and <> virtual events are difficult if not impossible to access with a Portuguese keyboard layout. One possible solution, which I chose many years ago, is to memorize the American keyboard layout and use that layout for all programming and command-line work, regardless of the actual labels on your keys. Although not really that difficult, this is a step that most people will understandably refuse to take. A more acceptable solution is to avoid using non-alphanumeric characters, which tend to vary a lot more from one layout to the other. I also tried to bind semantically similar virtual events to neighbouring keys, as is already the case with the standard clipboard shortcuts, which occupy 3 neighbouring keys in the same row (x, c and v). For instance, all find commands are placed sequentially in the same row (f, g, h, j and k). All save commands are placed in neighbouring keys (s, e and r). The dedent and indent events are moved to the same row as 4 other events that affect a region, like comment and uncomment (numeric keys row, 1 to 9), along with some other events associated with tabs. Finally, 2 of the most used virtual events, <> and <>, are now bound to and , which should be much more obvious than and . The old bindings are hard to understand unless you have a history of Emacs ab^H^Huse, and are not as intuitive as using the arrows with a modifier key. Extension bindings ------------------ The key bindings for virtual events belonging to IDLE extensions are currently defined in config-extensions.def and are not customizable directly from IDLE. Since 4 of these virtual events currently use the Alt modifier, they conflict with the above rationale of using one single modifier key for all shortcuts, viz. the Control key. I propose to expand these currents shortcuts with another key bindings that fits in with the proposed [IDLE Modern] scheme: format-paragraph= expand-word= zoom-height= run-module= # unchanged check-module= Binding changes --------------- Comparison of [IDLE Modern] bindings to [IDLE Classic Windows] bindings: a) Identical bindings: beginning-of-line= close-all-windows= # modifier-q is a standard binding for 'quit' in Mac (increasingly used in Windows) copy= # modifier-c is a standard binding 'copy' in Windows and Mac cut= # modifier-x is a standard binding 'cut' in Windows and Mac do-nothing= end-of-file= find= # modifier-f is a standard binding for 'find' in Windows and Mac newline-and-indent= open-new-window= # modifier-n is a standard binding for 'new' in Windows and Mac open-window-from-file= # modifier-o is a standard binding for 'open' in Windows and Mac paste= # modifier-v is a standard binding for 'paste' in Windows and Mac print-window= # modifier-p is a standard binding for 'print' in Windows and Mac python-docs= remove-selection= replace= # modifier-h is a standard binding for 'replace' in Windows and Mac save-window= # modifier-s is a standard binding for 'save' in Windows and Mac select-all= # modifier-a is a standard binding for 'select-all' in Windows and Mac smart-backspace= smart-indent= undo= # modifier-z is a standard binding for 'undo' in Windows and Mac view-restart= b) Similar bindings (Alt or Meta modifier replaced with Control modifier): comment-region= open-module= uncomment-region= tabify-region= untabify-region= c) Changed bindings: center-insert= change-indentwidth= close-window= # modifier-w is a standard binding for 'close-window' in Mac (increasingly used in Windows) dedent-region= find-again= # modifier-g is a standard binding for 'find-again' in Windows and Mac find-in-files= find-selection= goto-line= # modifier-l is a common but not standard binding for 'goto-line' in Windows and Mac history-next= history-previous= indent-region= interrupt-execution= open-class-browser= plain-newline-and-indent= python-context-help= redo= # modifier-y is a common but not standard binding for 'redo' in Windows and Mac restart-shell= save-copy-of-window-as-file= save-window-as-file= toggle-auto-coloring= toggle-tabs= Bindings ordered by key ----------------------- smart-backspace= remove-selection= beginning-of-line= newline-and-indent= smart-indent= python-docs= view-restart= restart-shell= python-context-help= do-nothing= history-previous= history-next= dedent-region= indent-region= comment-region= uncomment-region= tabify-region= untabify-region= change-indentwidth= toggle-tabs= toggle-auto-coloring= select-all= open-class-browser= copy= end-of-file= save-window-as-file= find= find-again= replace= interrupt-execution= find-selection= find-in-files= goto-line= open-module= open-new-window= open-window-from-file= print-window= close-all-windows= save-copy-of-window-as-file= save-window= center-insert= plain-newline-and-indent= paste= close-window= cut= redo= undo= ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-12 14:10 Message: Logged In: YES user_id=819035 Thanks for the instructive comments. Here are some answers: 1) The problems are the following: a) The standard key bindings are the IDLE Classic Windows key bindings, which do not work. - None of the many bindings that use the Alt modifier work, since the Alt (a.k.a. Option) key is used in MacOSX for accents and symbols. b) The IDLE Classic Mac key bindings do not work. - Most of them require the Command key, which for some unknown reason do not seem to work. c) The IDLE Classic Unix key bindings mostly work, but are unsatisfactory. - These bindings replace many "chord" key bindings with emacs style shortcuts, which are frankly unpleasant to use for 99% of people not used to emacs. Also, there are still several of these Unix key bindings that use the Alt modifier, and which thus do not work in MacOSX. In spite of all this, it is the most usable of the 3 default schemes. d) 5 key bindings used by extensions are currently not rebindable: Alt-Key-q, Alt-Key-slash, Alt-Key-2, Alt-Key-x and Key-F5. Since 4 of them use the Alt modifier, they do not work under MacOSX e) Some bits of extend.txt and help.txt are outdated. 2) A slightly awkward workaround to problem 1.b: What I meant was that by replacing Command with Meta in key bindings means that many but far from all Command bindings work. By chance, I discovered that using the Control-Command combination instead of just the Command modifier makes most if not all Meta bindings work. It seems as if Meta really is interpreted as Control-Command, with Command working sometimes. This is not very satisfactory, but it's better than any of the other 3 default bindings. 3) Regarding capitalization: I discovered by accident that Tk keybindings are case sensitive. However, all bindings mentioned by me treat capitals and lowercase letters identically, i.e. when I wrote Command-B, I really meant Command-b, and not Command-Shift-b. I'll take care not make that confusion from now on. 4) Command-b and Control-b: The bindings mentioned in my 2003-07-11 18:48 message are Command bindings. Command-b and Command-f really do move to the beginning and end of words, unlike Control-b and Control-f, which move one character back and one character forward. I have no idea why some these Command bindings work, but the fact is they do. 5) It might be useful to get other MacOSX users to check my findings, since there might quirks with my configuration which I'm not aware of. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 15:43 Message: Logged In: YES user_id=149084 Thank you for reporting the issues with help.txt and extend.txt. I will update these files. You are correct about the renaming, extend.txt has not been updated since the new config system was implemented. I agree it would be nice to set the extension configuration from the configuration dialog. However, we are much too close to release to contemplate doing that for 2.3. The extension feature is intended to incorporate 3rd party features so the enhancement of the config dialog would have to be suitably general. Your problem appears to be down to one thing: none of IDLE's "Classic Mac" Command combinations in your config-keys.def work. If I understand you correctly, you are saying that e.g. replacing "Command-Key-w" by "Meta-Key-w" in config-keys.def causes the <> event to work correctly? Note that Tk is very picky about capitalization. "Command-Key-w" is not the same as "Command-Key-W". Please be sure that your file is correct in this regard. If you can get everything working by doing this, would you please upload the modified version of your config-keys.def and let me know what the remaining problems are, if any. In your messages you have variously said that both "Command-B" and "Ctl-b" keystrokes go to the beginning of a word. Is this correct? And do you really mean "Apple/Shift/b" in the first case? The Ctl-b binding and others like it that you have mentioned in your earlier message are part of a number of default Tk bindings that have not been disabled in IDLE. http://www.tcl.tk/man/tcl8.3/TkCmd/text.htm#M141 Clearly, there may not be complete compatibility with this documentation in the Tk Mac implementation. But that is the origin of the bindings. By the way, the way to customize is not to modify config-keys.def, but to modify your .idlerc/config-keys.cfg or any of the other files in that directory. That is what the config dialog does, and it is quite all right to modify it manually as long as you carefully follow the format. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 14:08 Message: Logged In: YES user_id=819035 The file extend.txt references two files that do not exist: keydefs and config.txt I suppose the former corresponds config-keys.def, while the latter has been split into 3 files: config-main.def, config-extensions.def and config-highlight.def. Is this correct? Looking into config-extensions.def, I can finally see were those non-standard key sequences are defined: [FormatParagraph_cfgBindings] format-paragraph= (...) [AutoExpand_cfgBindings] expand-word= (...) [ZoomHeight_cfgBindings] zoom-height= (...) [ScriptBinding_cfgBindings] run-module= check-module= It would nice if these key bindings for extension modules could be put in the same file as the standard key bindings. Even nicer if the configuration dialog could be used to change all key bindings. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 13:48 Message: Logged In: YES user_id=819035 Using the original [IDLE Classic Mac] shortcut keys definitions, the only Command shortcuts that do anything are the following: Command-Q: tries to quit X11 instead of IDLE Command-W: closes X11 windows instead of IDLE windows Command-B: go to beginning of word Command-F: go to end of word Command-D: delete next word Command-H: hide X11 Command-M: minimize window Command-,: X11 preferences dialog ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 13:43 Message: Logged In: YES user_id=819035 Sorry, my confusion. Since I edited my original config-keys.def file, I forgot that the [IDLE Classic Mac] shortcuts used the Command modifier, and not Alt. This confusion is only made in my last message. If you replace "Command" with "Alt" in that message, everything makes sense: """ If I change all keybinding using the Command-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Command, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. """ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-11 13:22 Message: Logged In: YES user_id=149084 First, I would like you to answer this question: "What Alt keybindings are in the [IDLE Classic Mac] section of your config-keys.def and how did they get there, since there are none in the distributed version of that file?" Then, please read extend.txt and review the config-extensions.def file. The current implementation of the configuration dialog does not have the ability to customize the extension keybindings. It may be possible to provide a special version of config-extensions.def for the Mac. I will investigate. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 11:32 Message: Logged In: YES user_id=819035 With respect to problem 2, there is an easy workaround, although it's not the ideal solution. If I change all keybinding using the Alt-key in the [IDLE Classic Mac] section of config-keys.def to use Meta instead of Alt, suddenly many of the shortcuts work using the Command key (a.k.a Apple key). However, it seems that those shortcuts that are already being used by X11 take precedence: Command-Q tries to quit X11 and not IDLE and Command-W closes any X11 window, not just IDLE windows. There is a simple workaround to this problem. For some reason, if we use the Control-Command combination for Meta instead of just the Command key, most shortcuts seem to work. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-11 11:22 Message: Logged In: YES user_id=819035 With respect to question 3 in a previous message, some keybindings seem to be hardcoded: <> command, from AutoExpand.py: Defined somewhere as . <> command, from ZoomHeight.py: Defined as in TreeWidget.py. <> command, from FormatParagraph.py: Defined somewhere as . <> and <> commands, from ScriptBinding.py: Defined somewhere as and . Several commands from files Bindings.py, EditorWindow.py and PyShell.py do not have any key bindings: <>, <>, <>, <>, <>, <>, <>, <>, <>, <> and <>. It would be cool to have keybindings for some of these, and even cooler to be able to rebind them. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 14:56 Message: Logged In: YES user_id=819035 With respect to item 5) in my previous message (user-friendly dialog boxes), the Tab key can be used to cycle between buttons, which in conjunction with the Return key improves keyboard usability a lot. ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 14:51 Message: Logged In: YES user_id=819035 Keeping in mind Guido's goal of releasing Python2.3 by August 1st (so that it can be included with MacOSX 10.3), we should strive to make IDLE more Mac-friendly before that date: In order to do this, we have to correct a few problems: 1) IDLE for MacOSX should use the [IDLE Classic Mac] keyset by default. Users should not be forced discover that the key-bindings can be changed and then having to explicitly change the configuration. We want to attract newbies to Python, and IDLE should be the ideal tool for that. 2) The shortcut keys should work correctly. Currently none of the key combinations that use the Command-key work for me, which forces me to use the mouse and the menus. The clipboard shortcuts (Com-C, Com-X, Com-V) do not work, and other common shortcuts (Com-S, Com-N, Com-O, Com-W) don't work either. Com-Q works, but it tries to exit X11 altogether, instead of closing IDLE. I know Mac users are used to using the mouse, but power-users are also used to having the usual Command-key shortcuts (e.g. Command-S to save a file). I've tried most shortcuts, and the only ones that seem to work for me are: remove-selection= smart-backspace= newline-and-indent= smart-indent= beginning-of-line= end-of-file= (same as Delete key) history-next= history-previous= interrupt-execution= restart-shell= comment-region= uncomment-region= tabify-region= untabify-region= toggle-auto-coloring= toggle-tabs= change-indentwidth= find-again= (only the latter works) Some shortcuts do not seem do to anything, although I might be mistaken since I do not know exactly what they are meant to do: center-insert= view-restart= do-nothing= The End key works correctly, although there is no end-of-line entry in the config-keys.def corresponding to it, as there is for the Home key (beginning-of-line= ). The usual Windows shortcuts work: Ctl-Home, Ctl-End, Ctl-Up, Ctl-Down, Ctl-Left, Ctl-Right Some common emacs bindings work as well (I only tested the most basic bindings): Ctl-p, Ctl-n, Ctl-b, Ctl-f, Ctl-a, Ctl-e 3) Eliminate incorrect shortcuts from menus. Although none of the shortcuts listed in the [IDLE Classic Mac] section of file /usr/local/lib/python2.3/idlelib/config-keys.def uses the Alt key, several menus show shortcuts that use that key (and which do not work): - In the Python Shell window: Edit -> Expand Word (Alt-/) Windows -> Zoom Height (Alt-2) - In the Editor window: Format -> Format Paragraph (Alt-Q) Run -> Check Module (Alt-X) There doesn't seem to be any entry in config-keys.def corresponding to these shortcuts. 4) The "IDLE Help" window should be updated. Currently, it lists a few shortcuts that do not work in MacOSX. Quoting: """ Command history: Alt-p retrieves previous command matching what you have typed Alt-n retrieves next Return while on any previous command retrieves that command Alt-/ (Expand word) is also useful here """ A help document that gives incorrect information is worse than having no information. 5) Dialog Boxes should be keyboard friendly. Presently I cannot use the keyboard to choose Dialog Box buttons (Yes or No buttons, for instance). The only keys that seem to work are Escape and Return. 6) Menus should be keyboard friendly. The Alt-Underlined_Letter method that is used to navigate menus in the Windows world doesn't seem to work with IDLE in MacOSX. Although this doesn't seem to be documented, F10 can be used to open the first menu item, which enables us to operate menus with the keyboard although this is not as efficient as direct menu access. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 11:42 Message: Logged In: YES user_id=149084 The "Classic Mac" keyset uses Control-Key-n for history-next and Control-Key-p for history-previous. The Alt key isn't used in this keyset. (The keyset is defined in config-keys.def) Are you saying that when "Classic Mac" is set that Alt key accelerators are appearing in the menus? ---------------------------------------------------------------------- Comment By: Tiago Castro Henriques (tiagoh) Date: 2003-07-10 08:52 Message: Logged In: YES user_id=819035 I've tried all three of the Built-in key sets, and the problem remains. I tried restarting idle to see if that was the problem, but I still have the same problem. Maybe there is something I'm missing, but it doesn't seem obvious to me how to make it work. Unless I'm doing something stupid, this would be a serious defect with respect to IDLE usability under MacOSX ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-10 00:25 Message: Logged In: YES user_id=149084 It sounds to me like you don't have the Mac bindings enabled. Try Options / Configure IDLE / Keys and select the IDLE Classic Mac Key Set ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=768469&group_id=5470 From noreply@sourceforge.net Tue Jul 29 08:09:08 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 00:09:08 -0700 Subject: [Python-bugs-list] [ python-Bugs-778964 ] parameter confusion in 2.3c2 Message-ID: Bugs item #778964, was opened at 2003-07-28 21:47 Message generated for change (Comment added) made by blaforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) Summary: parameter confusion in 2.3c2 Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Bill la Forge (blaforge) Date: 2003-07-29 14:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 11:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 11:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 10:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 22:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply@sourceforge.net Tue Jul 29 10:01:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 02:01:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-779460 ] plistlib should be moved out of plat-mac Message-ID: Bugs item #779460, was opened at 2003-07-29 05: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=779460&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Sarwat Khan (sarwatfoo) Assigned to: Nobody/Anonymous (nobody) Summary: plistlib should be moved out of plat-mac Initial Comment: plistlib doesn't (I think, it shouldn't anyway) have any Mac dependancies and should be moved out of plat-mac so plists can be generated and parsed on non-Mac platforms. I intend to use it, for example, on a Linux web server in CGI scripts for basic XML handling. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779460&group_id=5470 From noreply@sourceforge.net Tue Jul 29 10:22:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 02:22:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-778964 ] parameter confusion in 2.3c2 Message-ID: Bugs item #778964, was opened at 2003-07-28 16:47 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) Summary: parameter confusion in 2.3c2 Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 11:22 Message: Logged In: YES user_id=45365 The fact that you can't easily isolate it strengthens my hunch that this is not a general issue. The code looks distinctly fishy, and the description also doesn't match the code fragement (although that could well be the result of you pulling this out of a large package). Note that you talk about parameters being passed to crjentPje, but that isn't a baseclass of StartOfJel. I suggest you single-step the code in a debugger, to check that what really happens actually matches what you think is happening... ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 09:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 06:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 06:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 05:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 17:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply@sourceforge.net Tue Jul 29 10:28:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 02:28:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-779469 ] slices section in "what's new" has invalid example code Message-ID: Bugs item #779469, was opened at 2003-07-29 11: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=779469&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: slices section in "what's new" has invalid example code Initial Comment: In section 15 of the What's New docs for Python 2.3c2 (on extended slices for builtin types), the last example has this line: return FakeSeq([self.calc_item(i) in range(*indices)]) which should surely read: return FakeSeq([self.calc_item(i) for i in range(*indices)]) http://www.python.org/doc/2.3c2/whatsnew/section-slices.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779469&group_id=5470 From noreply@sourceforge.net Tue Jul 29 10:40:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 02:40:16 -0700 Subject: [Python-bugs-list] [ python-Bugs-778964 ] parameter confusion in 2.3c2 Message-ID: Bugs item #778964, was opened at 2003-07-28 21:47 Message generated for change (Comment added) made by blaforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) Summary: parameter confusion in 2.3c2 Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Bill la Forge (blaforge) Date: 2003-07-29 16:40 Message: Logged In: YES user_id=22406 Then by all means close this bug report. My sincere desire is that this is NOT a general issue. Also my hands are a bit tied as the client is NOT willing that I release this code. All the best, and thanks to everyone for the great software-- Python's the Best! blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 16:22 Message: Logged In: YES user_id=45365 The fact that you can't easily isolate it strengthens my hunch that this is not a general issue. The code looks distinctly fishy, and the description also doesn't match the code fragement (although that could well be the result of you pulling this out of a large package). Note that you talk about parameters being passed to crjentPje, but that isn't a baseclass of StartOfJel. I suggest you single-step the code in a debugger, to check that what really happens actually matches what you think is happening... ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 14:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 11:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 11:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 10:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 22:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply@sourceforge.net Tue Jul 29 10:41:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 02:41:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-778964 ] parameter confusion in 2.3c2 Message-ID: Bugs item #778964, was opened at 2003-07-28 21:47 Message generated for change (Settings changed) made by blaforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) Summary: parameter confusion in 2.3c2 Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 16:40 Message: Logged In: YES user_id=22406 Then by all means close this bug report. My sincere desire is that this is NOT a general issue. Also my hands are a bit tied as the client is NOT willing that I release this code. All the best, and thanks to everyone for the great software-- Python's the Best! blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 16:22 Message: Logged In: YES user_id=45365 The fact that you can't easily isolate it strengthens my hunch that this is not a general issue. The code looks distinctly fishy, and the description also doesn't match the code fragement (although that could well be the result of you pulling this out of a large package). Note that you talk about parameters being passed to crjentPje, but that isn't a baseclass of StartOfJel. I suggest you single-step the code in a debugger, to check that what really happens actually matches what you think is happening... ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 14:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 11:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 11:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 10:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 22:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply@sourceforge.net Tue Jul 29 11:31:25 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 03:31:25 -0700 Subject: [Python-bugs-list] [ python-Bugs-778964 ] parameter confusion in 2.3c2 Message-ID: Bugs item #778964, was opened at 2003-07-28 21:47 Message generated for change (Comment added) made by blaforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 >Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) Summary: parameter confusion in 2.3c2 Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Bill la Forge (blaforge) Date: 2003-07-29 17:31 Message: Logged In: YES user_id=22406 I reopened this because I learned something that might be helpful--I only have problems with 2.3c2 when invoked via a bat script. When run from a DOS command prompt, I have no problem. blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 16:40 Message: Logged In: YES user_id=22406 Then by all means close this bug report. My sincere desire is that this is NOT a general issue. Also my hands are a bit tied as the client is NOT willing that I release this code. All the best, and thanks to everyone for the great software-- Python's the Best! blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 16:22 Message: Logged In: YES user_id=45365 The fact that you can't easily isolate it strengthens my hunch that this is not a general issue. The code looks distinctly fishy, and the description also doesn't match the code fragement (although that could well be the result of you pulling this out of a large package). Note that you talk about parameters being passed to crjentPje, but that isn't a baseclass of StartOfJel. I suggest you single-step the code in a debugger, to check that what really happens actually matches what you think is happening... ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 14:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 11:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 11:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 10:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 22:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply@sourceforge.net Tue Jul 29 11:49:06 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 03:49:06 -0700 Subject: [Python-bugs-list] [ python-Bugs-778964 ] parameter confusion in 2.3c2 Message-ID: Bugs item #778964, was opened at 2003-07-28 21:47 Message generated for change (Comment added) made by blaforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) Summary: parameter confusion in 2.3c2 Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Bill la Forge (blaforge) Date: 2003-07-29 17:49 Message: Logged In: YES user_id=22406 Solved! It looks very much like I'm getting a bad seed for random when running from a batch file. (My code depends on unique 128-bit random numbers for proper functioning--I've written my own secure random method that sits on top of random.) Anyway, the fix for me that makes 2.3c work fine is to provide my own seed to random: random.Random(time.time()) blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 17:31 Message: Logged In: YES user_id=22406 I reopened this because I learned something that might be helpful--I only have problems with 2.3c2 when invoked via a bat script. When run from a DOS command prompt, I have no problem. blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 16:40 Message: Logged In: YES user_id=22406 Then by all means close this bug report. My sincere desire is that this is NOT a general issue. Also my hands are a bit tied as the client is NOT willing that I release this code. All the best, and thanks to everyone for the great software-- Python's the Best! blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 16:22 Message: Logged In: YES user_id=45365 The fact that you can't easily isolate it strengthens my hunch that this is not a general issue. The code looks distinctly fishy, and the description also doesn't match the code fragement (although that could well be the result of you pulling this out of a large package). Note that you talk about parameters being passed to crjentPje, but that isn't a baseclass of StartOfJel. I suggest you single-step the code in a debugger, to check that what really happens actually matches what you think is happening... ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 14:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 11:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 11:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 10:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 22:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply@sourceforge.net Tue Jul 29 11:59:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 03:59:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-779506 ] strftime returns empty strings with %Z when giving instant Message-ID: Bugs item #779506, was opened at 2003-07-29 03: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=779506&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Nobody/Anonymous (nobody) Summary: strftime returns empty strings with %Z when giving instant Initial Comment: I begin with %Z, no instant: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z') '2003-07-29 03.49.17 PDT' now I add the instant: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z', time.localtime()) '' variation on the same: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z', time.localtime(time.time())) '' and now I drop the %Z but keep the instant: >>> time.strftime('%Y-%m-%d %I.%M.%S', time.localtime(time.time())) '2003-07-29 03.51.42' my build info: >>> import sys; sys.version '2.3c2 (#1, Jul 28 2003, 13:47:18) \n[GCC 2.95.2 19991024 (release)]' this is on Darwin 5.5 (Mac OS X 10.1.5) using a framework installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779506&group_id=5470 From noreply@sourceforge.net Tue Jul 29 12:42:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 04:42:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-779506 ] strftime returns empty strings with %Z when giving instant Message-ID: Bugs item #779506, was opened at 2003-07-29 06:59 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779506&group_id=5470 >Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) >Assigned to: Jack Jansen (jackjansen) Summary: strftime returns empty strings with %Z when giving instant Initial Comment: I begin with %Z, no instant: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z') '2003-07-29 03.49.17 PDT' now I add the instant: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z', time.localtime()) '' variation on the same: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z', time.localtime(time.time())) '' and now I drop the %Z but keep the instant: >>> time.strftime('%Y-%m-%d %I.%M.%S', time.localtime(time.time())) '2003-07-29 03.51.42' my build info: >>> import sys; sys.version '2.3c2 (#1, Jul 28 2003, 13:47:18) \n[GCC 2.95.2 19991024 (release)]' this is on Darwin 5.5 (Mac OS X 10.1.5) using a framework installation. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-29 07:42 Message: Logged In: YES user_id=33168 These work for me on Linux (rh9). My guess is that this is a platform specific problem. Jack, can you test/confirm this behaviour? boredzo how did you find this problem? Did a test fail or did you just discover it? Perhaps we should add a test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779506&group_id=5470 From noreply@sourceforge.net Tue Jul 29 13:14:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 05:14:50 -0700 Subject: [Python-bugs-list] [ python-Bugs-778964 ] parameter confusion in 2.3c2 Message-ID: Bugs item #778964, was opened at 2003-07-28 21:47 Message generated for change (Comment added) made by blaforge You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bill la Forge (blaforge) Assigned to: Nobody/Anonymous (nobody) Summary: parameter confusion in 2.3c2 Initial Comment: class crjentPje(PJE): def __init__ (self,uuri,headline,actorName,jentProxy,lelProxy=None,p op='',op='',jelType='L1PJENT.PJENT',ts='NoName'): Cache.PJE.__init__(self,uuri,actorName,'*',pop+' |'+headline+'|',ts=ts) class StartOfJel(PJE): def __init__ (self,uuri,jelName,actorName,partOfProxy=None,jelType ='L1JelTypes.JEL',ts='NoName'): Cache.PJE.__init__ (self,uuri,actorName,'`','StartOfJel',ts=ts) self['*JelName']=jelName self['*JelType']=jelType if partOfProxy: self['*PartOf']=partOfProxy.uuri About 1 time in 10 when running 2.3c2, when creating a StartOfJel, the partOfProxy ended up being passed as the uuri parameter to crjentPje!!! (I was passing None as the value for the uuri parameter.) The problem vanishes when I fall back to 2.2. ---------------------------------------------------------------------- >Comment By: Bill la Forge (blaforge) Date: 2003-07-29 19:14 Message: Logged In: YES user_id=22406 Stranger and stranger While setting the seed fixes it for me, I still can't reduce the script to recreate the problem! (frustrated) ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 17:49 Message: Logged In: YES user_id=22406 Solved! It looks very much like I'm getting a bad seed for random when running from a batch file. (My code depends on unique 128-bit random numbers for proper functioning--I've written my own secure random method that sits on top of random.) Anyway, the fix for me that makes 2.3c work fine is to provide my own seed to random: random.Random(time.time()) blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 17:31 Message: Logged In: YES user_id=22406 I reopened this because I learned something that might be helpful--I only have problems with 2.3c2 when invoked via a bat script. When run from a DOS command prompt, I have no problem. blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 16:40 Message: Logged In: YES user_id=22406 Then by all means close this bug report. My sincere desire is that this is NOT a general issue. Also my hands are a bit tied as the client is NOT willing that I release this code. All the best, and thanks to everyone for the great software-- Python's the Best! blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 16:22 Message: Logged In: YES user_id=45365 The fact that you can't easily isolate it strengthens my hunch that this is not a general issue. The code looks distinctly fishy, and the description also doesn't match the code fragement (although that could well be the result of you pulling this out of a large package). Note that you talk about parameters being passed to crjentPje, but that isn't a baseclass of StartOfJel. I suggest you single-step the code in a debugger, to check that what really happens actually matches what you think is happening... ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 14:09 Message: Logged In: YES user_id=22406 Lets say that its too late. This bug is more obscure than I had thought. It also can not be isolated. I tracked the problem down to my UURI generator, which returns nice random 128 bit base-32 encoded strings. In one test case only it returns the same UURI as passed by that other parameter. Note that the other parameter is NOT passed to the UURI generator. I'm saying that a code fragment can not be generated because one of my regression tests checks to make sure the UURI generator doesn't return duplicate values. And that test still works fine. I'm finding this all very peculilar. One other thing I'll note in passing is that the more print statements I put in the code, the less likely any given test is to fail. With no print statements, failure occurs about half the time. With lots of print statements, failure is about 1 in 20. The whole program is about 30K (compressed). Its also hard to spot when the error occurs, as the error destroys data which causes a subsequent failure. (Though knowing the error, I can now add additional checks.) As the code is confidential and propriatary, I'll need permission from the client to send it, as well. blaforge ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-29 11:39 Message: Logged In: YES user_id=12800 The most important thing right now is to get an isolated, runnable script that we can use to try to reproduce the problem. Without this, we're at a loss, and time is rapidly running out for us to be able to do anything for Python 2.3 final (if it hasn't already run out). ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 11:31 Message: Logged In: YES user_id=22406 Bad news. I'm running 2000 with service pack 3. I moved the code to another 2000 system (with no service pack). Code still runs under 2.2 but not under 2.3. ;-( blaforge ---------------------------------------------------------------------- Comment By: Bill la Forge (blaforge) Date: 2003-07-29 10:06 Message: Logged In: YES user_id=22406 I'm running MS Windows 2000 and did the standard python windows install. So you can't blame my build! Its real. And yes, this is a pretty basic flaw, and intermittent at that! (about 1 out of ten runs failing.) I'll see what I can do about isolation. (Being in India has its advantages.) My guess is that a small change to the signiture will fix this, which doesn't help anyone else, as this bug will likely haunt 2.3 if not caught. blaforge ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-28 22:15 Message: Logged In: YES user_id=45365 My gut feeling says that if something this basic isn't working there is probably something in your setup wrong, or something in the way you built Python, or some such. The reasoning behind this is that something so essential as parameters being mixed up would have shown up earlier. But: there is also the possibility that you have found a genuine bug, and then it is very serious. Unfortunately the bug report as it is now doesn't allow for easy duplication. We can try if you can provide the following: - an isolated runnable script that shows the problem - exact details on your Python version, OS version, any other details that may be pertinent - a recipy for running the script to see the problems. As Python 2.3 is scheduled for tomorrow there is a bit of a hurry here... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778964&group_id=5470 From noreply@sourceforge.net Tue Jul 29 13:21:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 05:21:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-779506 ] strftime returns empty strings with %Z when giving instant Message-ID: Bugs item #779506, was opened at 2003-07-29 12:59 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779506&group_id=5470 Category: Macintosh Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mac-arena the Bored Zo (boredzo) Assigned to: Jack Jansen (jackjansen) Summary: strftime returns empty strings with %Z when giving instant Initial Comment: I begin with %Z, no instant: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z') '2003-07-29 03.49.17 PDT' now I add the instant: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z', time.localtime()) '' variation on the same: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z', time.localtime(time.time())) '' and now I drop the %Z but keep the instant: >>> time.strftime('%Y-%m-%d %I.%M.%S', time.localtime(time.time())) '2003-07-29 03.51.42' my build info: >>> import sys; sys.version '2.3c2 (#1, Jul 28 2003, 13:47:18) \n[GCC 2.95.2 19991024 (release)]' this is on Darwin 5.5 (Mac OS X 10.1.5) using a framework installation. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-29 14:21 Message: Logged In: YES user_id=45365 It works for me, on MacOSX 10.2.6: >>> time.strftime('%Y-%m-%d %I.%M.%S %Z', time.localtime(time.time())) '2003-07-29 02.22.10 CEST' I haven't tested anything on 10.1 for a long time, I'll do so later this week. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-29 13:42 Message: Logged In: YES user_id=33168 These work for me on Linux (rh9). My guess is that this is a platform specific problem. Jack, can you test/confirm this behaviour? boredzo how did you find this problem? Did a test fail or did you just discover it? Perhaps we should add a test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779506&group_id=5470 From noreply@sourceforge.net Tue Jul 29 13:49:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 05:49:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-777588 ] asyncore is broken for windows if connection is refused Message-ID: Bugs item #777588, was opened at 2003-07-25 14:43 Message generated for change (Comment added) made by johnjsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777588&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Garth Bushell (garth42) Assigned to: Nobody/Anonymous (nobody) Summary: asyncore is broken for windows if connection is refused Initial Comment: asyncore.poll is broken on windows. If a connection is refused happens it will hang for ever and never raise an exception. The Select statment never checks the exfds. This is needed as this is where windows reports failed connections. The documentation in the microsoft platform SDK mentions this. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/select_2.asp The suggested fix is shown below althought this is untested. The correct error number is recived from getsockopt(SOL_SOCKET,SO_ERROR) def poll(timeout=0.0, map=None): if map is None: map = socket_map if map: r = []; w = []; e = [] for fd, obj in map.items(): if obj.readable(): r.append(fd) if obj.writable(): w.append(fd) if sys.platform == 'win32': if not obj.connected: e.append(fd) if [] == r == w == e: time.sleep(timeout) else: try: r, w, e = select.select(r, w, e, timeout) except select.error, err: if err[0] != EINTR: raise else: return if sys.platform == 'win32': for fd in e: obj = map.get(fd) if obj is None: continue errno = fs.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) raise socket.error,(errno,socketerrorTab[error]) for fd in r: obj = map.get(fd) if obj is None: continue read(obj) for fd in w: obj = map.get(fd) if obj is None: continue write(obj) ---------------------------------------------------------------------- Comment By: John J Smith (johnjsmith) Date: 2003-07-29 12:49 Message: Logged In: YES user_id=830565 I was bitten by the same problem. My workaround (in a Tkinter application) is given below. Would it make sense to modify poll() to simply add the union of r and w to e, and call handle_error() for any fd in e? Workaround: try: self.connect(send_addr) except socket.error: self.handle_error() if sys.platform == 'win32': # Win98 select() doesn't seem to report errors for a # non-blocking connect(). self.__connected = 0 self.__frame.after(2000, self.__win_connect_poll) ... if sys.platform == 'win32': def __win_connect_poll (self): if self.__connected: return e = self.socket.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) if e in (0, errno.EINPROGRESS, errno.WSAEINPROGRESS): self.__frame.after(2000, self.__win_connect_poll) else: try: str = socket.errorTab[e] except KeyError: str = os.strerror(e) try: raise socket.error(e, str) except socket.error: self.handle_error() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777588&group_id=5470 From noreply@sourceforge.net Tue Jul 29 18:04:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 10:04:13 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-764188 ] setvbuf for File object Message-ID: Feature Requests item #764188, was opened at 2003-07-01 20:21 Message generated for change (Comment added) made by yueluo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yue Luo (yueluo) Assigned to: Nobody/Anonymous (nobody) Summary: setvbuf for File object Initial Comment: I wonder if it is possible to add a new method setvbuf to File object. The method does the same as the setvbuf() in stdio.h. ---------------------------------------------------------------------- >Comment By: Yue Luo (yueluo) Date: 2003-07-29 17:04 Message: Logged In: YES user_id=806666 The -u command line option is not what I had in mind, but it will achieve exactly what I wanted. I just did not know that it exists. Maybe this request can be closed. Can I use the optional bufsize to file(), open(), to change the buffer mode of the standard output? The stdout and stderr are already opened. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-29 00:27 Message: Logged In: YES user_id=832557 There is already an optional bufsize argument to file(), open() and fdopen(). It allows you to specify unbuffered (0), line buffered (1), system default (-1) or buffered usage with a specific buffer size (>1). Are you requesting something different? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 06:57 Message: Logged In: YES user_id=21627 I see. Can you explain why invoking "python -u" is insufficient? ---------------------------------------------------------------------- Comment By: Yue Luo (yueluo) Date: 2003-07-07 23:14 Message: Logged In: YES user_id=806666 Sorry, I did not make myself clear. I just want to be able to change the buffer size or the buffer mode of a file object. Especially, I often want to change the standard output buffer mode to line buffer so that I can see the result immediately even when the output has been redirected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 22:08 Message: Logged In: YES user_id=21627 What buf argument would you like to pass? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 From noreply@sourceforge.net Tue Jul 29 18:25:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 10:25:21 -0700 Subject: [Python-bugs-list] [ python-Bugs-778400 ] IDLE hangs when selecting "Edit with IDLE" from explorer Message-ID: Bugs item #778400, was opened at 2003-07-27 05:32 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778400&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Tim Peters (tim_one) Summary: IDLE hangs when selecting "Edit with IDLE" from explorer Initial Comment: IDLE editor window hangs when right clicking a file and selecting "Edit with IDLE" Steps to reproduce: o Open IDLE o Open explorer o Right click on a .py file o Choose "Edit with IDLE" A new IDLE edit window opens but it is not responding. The original (shell) IDLE window works fine. If you do the above without opening an IDLE shell it works fine. My system is win2k on IBM T30 (LapTop). ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-29 13:25 Message: Logged In: YES user_id=31435 Yup, this just snuck in for 2.3 final. Thanks! Misc/NEWS; new revision: 1.830 PCbuild/python20.wse; new revision: 1.133 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-07-29 01:10 Message: Logged In: YES user_id=149084 Sorry, I should have used the -n switch the first time. Hopefully this can be 2.3. Currently on Windows IDLE can partially start multiple instances under conditions still not fully understood. The comment by tebeka is interesting but not a universal fix, I believe. If IDLE is configured to open a shell (the default) it will exhibit this behaviour. If configured to open an edit window at startup, it won't. The -n switch causes IDLE to not use the subprocess, so it acts like the old IDLE and mutliple copies are not a problem. I'm increasingly inclined to think that the -e switch should act like an "editor window on startup" configuration, since opening multiple shells is ugly when configured to "open shell on startup." Eventually it will be possible to run multiple IDLE instances, each with its own subprocess, but that's 2.4. ---------------------------------------------------------------------- Comment By: Miki Tebeka (tebeka) Date: 2003-07-28 03:10 Message: Logged In: YES user_id=358087 When I change idle.pyw from from idlelib.PyShell import main to import idlelib.PyShell idlelib.PyShell.main() I get a responsive IDLE edit window + a new shell window. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-27 12:53 Message: Logged In: YES user_id=31435 Assigned to Kurt. On Win2K the steps above don't create a problem for me, but I get a frozen window if I repeat the last two steps. The whole failing sequence for me on a Win2K desktop box: o Open IDLE o Right click on a .py file o Choose "Edit with IDLE" o Right click on another .py file o Choose "Edit with IDLE" On Win98SE, the first "Edit with IDLE" works fine. The second "Edit with IDLE" opens a new shell window but not a window for the selected .py file. Third and subsequent "Edit with IDLE" steps have no visible effect (neither a new shell nor a new edit window open). Something is left in a hosed state then: if I close all the open IDLE windows, and try "Edit with IDLE" again, nothing visible happens. The Win98SE task manager (Ctrl+Alt+Del) doesn't show any Python processes running at that point, and neither does WinTop. It's still possible to start another IDLE, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=778400&group_id=5470 From noreply@sourceforge.net Tue Jul 29 19:15:34 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 11:15:34 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-764188 ] setvbuf for File object Message-ID: Feature Requests item #764188, was opened at 2003-07-01 15:21 Message generated for change (Comment added) made by jbrouwers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Yue Luo (yueluo) Assigned to: Nobody/Anonymous (nobody) Summary: setvbuf for File object Initial Comment: I wonder if it is possible to add a new method setvbuf to File object. The method does the same as the setvbuf() in stdio.h. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-29 13:15 Message: Logged In: YES user_id=832557 Here's the best answer I can provide. Quoting from the O'Reilly book "Python in a Nutshell", page 188: "On some platforms, you can change the buffering for files already open, but there is no cross-platform way to do this". If Python file objects were enhanced with a new method, say bufsize(), to change the buffering of an open file, that method may not work for all file types or may not work on all platforms. That is probably OK, since there is nothing else Python could do and such platform specific behavior is not uncommon in Python. Btw, it is very common for stderr to be non-buffered and stdout to be buffered, by default. That may create an additional problems, for example output to stderr may show up before output stdout sent earlier. One way to avoid that is to flush stdout often. Another is, redirect stdout and stderr to a single pipe. ---------------------------------------------------------------------- Comment By: Yue Luo (yueluo) Date: 2003-07-29 12:04 Message: Logged In: YES user_id=806666 The -u command line option is not what I had in mind, but it will achieve exactly what I wanted. I just did not know that it exists. Maybe this request can be closed. Can I use the optional bufsize to file(), open(), to change the buffer mode of the standard output? The stdout and stderr are already opened. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-28 19:27 Message: Logged In: YES user_id=832557 There is already an optional bufsize argument to file(), open() and fdopen(). It allows you to specify unbuffered (0), line buffered (1), system default (-1) or buffered usage with a specific buffer size (>1). Are you requesting something different? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 01:57 Message: Logged In: YES user_id=21627 I see. Can you explain why invoking "python -u" is insufficient? ---------------------------------------------------------------------- Comment By: Yue Luo (yueluo) Date: 2003-07-07 18:14 Message: Logged In: YES user_id=806666 Sorry, I did not make myself clear. I just want to be able to change the buffer size or the buffer mode of a file object. Especially, I often want to change the standard output buffer mode to line buffer so that I can see the result immediately even when the output has been redirected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 17:08 Message: Logged In: YES user_id=21627 What buf argument would you like to pass? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 From noreply@sourceforge.net Tue Jul 29 20:43:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 12:43:31 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-764188 ] setvbuf for File object Message-ID: Feature Requests item #764188, was opened at 2003-07-01 22:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 Category: Python Library Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Yue Luo (yueluo) Assigned to: Nobody/Anonymous (nobody) Summary: setvbuf for File object Initial Comment: I wonder if it is possible to add a new method setvbuf to File object. The method does the same as the setvbuf() in stdio.h. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-07-29 21:43 Message: Logged In: YES user_id=21627 yueluo: In short, there is no way to change the buffering of stdout except by using -u. Since you seem to be happy with that approach, I'm closing this issue. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-29 20:15 Message: Logged In: YES user_id=832557 Here's the best answer I can provide. Quoting from the O'Reilly book "Python in a Nutshell", page 188: "On some platforms, you can change the buffering for files already open, but there is no cross-platform way to do this". If Python file objects were enhanced with a new method, say bufsize(), to change the buffering of an open file, that method may not work for all file types or may not work on all platforms. That is probably OK, since there is nothing else Python could do and such platform specific behavior is not uncommon in Python. Btw, it is very common for stderr to be non-buffered and stdout to be buffered, by default. That may create an additional problems, for example output to stderr may show up before output stdout sent earlier. One way to avoid that is to flush stdout often. Another is, redirect stdout and stderr to a single pipe. ---------------------------------------------------------------------- Comment By: Yue Luo (yueluo) Date: 2003-07-29 19:04 Message: Logged In: YES user_id=806666 The -u command line option is not what I had in mind, but it will achieve exactly what I wanted. I just did not know that it exists. Maybe this request can be closed. Can I use the optional bufsize to file(), open(), to change the buffer mode of the standard output? The stdout and stderr are already opened. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-29 02:27 Message: Logged In: YES user_id=832557 There is already an optional bufsize argument to file(), open() and fdopen(). It allows you to specify unbuffered (0), line buffered (1), system default (-1) or buffered usage with a specific buffer size (>1). Are you requesting something different? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 08:57 Message: Logged In: YES user_id=21627 I see. Can you explain why invoking "python -u" is insufficient? ---------------------------------------------------------------------- Comment By: Yue Luo (yueluo) Date: 2003-07-08 01:14 Message: Logged In: YES user_id=806666 Sorry, I did not make myself clear. I just want to be able to change the buffer size or the buffer mode of a file object. Especially, I often want to change the standard output buffer mode to line buffer so that I can see the result immediately even when the output has been redirected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 00:08 Message: Logged In: YES user_id=21627 What buf argument would you like to pass? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 From noreply@sourceforge.net Tue Jul 29 21:04:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 13:04:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-779825 ] plistlib and bundlebuilder not in the documentation Message-ID: Bugs item #779825, was opened at 2003-07-29 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=779825&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Nobody/Anonymous (nobody) Summary: plistlib and bundlebuilder not in the documentation Initial Comment: These two modules are not in the module reference (neither in the generic version, nor in the mac-specific version). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779825&group_id=5470 From noreply@sourceforge.net Tue Jul 29 21:05:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 13:05:41 -0700 Subject: [Python-bugs-list] [ python-Bugs-779825 ] plistlib and bundlebuilder not in the documentation Message-ID: Bugs item #779825, was opened at 2003-07-29 22:04 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779825&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None >Priority: 4 Submitted By: Ronald Oussoren (ronaldoussoren) >Assigned to: Just van Rossum (jvr) Summary: plistlib and bundlebuilder not in the documentation Initial Comment: These two modules are not in the module reference (neither in the generic version, nor in the mac-specific version). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779825&group_id=5470 From noreply@sourceforge.net Tue Jul 29 21:09:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 13:09:21 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-764188 ] setvbuf for File object Message-ID: Feature Requests item #764188, was opened at 2003-07-01 15:21 Message generated for change (Comment added) made by jbrouwers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 Category: Python Library Group: None Status: Closed Resolution: Works For Me Priority: 5 Submitted By: Yue Luo (yueluo) Assigned to: Nobody/Anonymous (nobody) Summary: setvbuf for File object Initial Comment: I wonder if it is possible to add a new method setvbuf to File object. The method does the same as the setvbuf() in stdio.h. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-29 15:09 Message: Logged In: YES user_id=832557 Well yes, but -u may not work everywhere either. Depends on the platform and some other conditions, like Tkinter. Check the Python source code for all details. Lastly, I have used '#!/.../python -u' as the first line in Python scripts and on RedHat Linux 8 it does work for my specific needs. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-29 14:43 Message: Logged In: YES user_id=21627 yueluo: In short, there is no way to change the buffering of stdout except by using -u. Since you seem to be happy with that approach, I'm closing this issue. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-29 13:15 Message: Logged In: YES user_id=832557 Here's the best answer I can provide. Quoting from the O'Reilly book "Python in a Nutshell", page 188: "On some platforms, you can change the buffering for files already open, but there is no cross-platform way to do this". If Python file objects were enhanced with a new method, say bufsize(), to change the buffering of an open file, that method may not work for all file types or may not work on all platforms. That is probably OK, since there is nothing else Python could do and such platform specific behavior is not uncommon in Python. Btw, it is very common for stderr to be non-buffered and stdout to be buffered, by default. That may create an additional problems, for example output to stderr may show up before output stdout sent earlier. One way to avoid that is to flush stdout often. Another is, redirect stdout and stderr to a single pipe. ---------------------------------------------------------------------- Comment By: Yue Luo (yueluo) Date: 2003-07-29 12:04 Message: Logged In: YES user_id=806666 The -u command line option is not what I had in mind, but it will achieve exactly what I wanted. I just did not know that it exists. Maybe this request can be closed. Can I use the optional bufsize to file(), open(), to change the buffer mode of the standard output? The stdout and stderr are already opened. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-28 19:27 Message: Logged In: YES user_id=832557 There is already an optional bufsize argument to file(), open() and fdopen(). It allows you to specify unbuffered (0), line buffered (1), system default (-1) or buffered usage with a specific buffer size (>1). Are you requesting something different? ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-08 01:57 Message: Logged In: YES user_id=21627 I see. Can you explain why invoking "python -u" is insufficient? ---------------------------------------------------------------------- Comment By: Yue Luo (yueluo) Date: 2003-07-07 18:14 Message: Logged In: YES user_id=806666 Sorry, I did not make myself clear. I just want to be able to change the buffer size or the buffer mode of a file object. Especially, I often want to change the standard output buffer mode to line buffer so that I can see the result immediately even when the output has been redirected. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-07-07 17:08 Message: Logged In: YES user_id=21627 What buf argument would you like to pass? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=764188&group_id=5470 From noreply@sourceforge.net Wed Jul 30 02:46:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 18:46:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-779973 ] Missing DEFS in Makefile.pre.in breakage Message-ID: Bugs item #779973, was opened at 2003-07-29 18: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=779973&group_id=5470 Category: Distutils Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Fazal Majid (majid) Assigned to: Nobody/Anonymous (nobody) Summary: Missing DEFS in Makefile.pre.in breakage Initial Comment: DEFS= is missing from the top-level Makefile.pre.in in Python 2.3 final. This causes quite a few older distutils C extension packages that rely on the presence of DEFS to break, e.g. DCOracle2-1.1 or python-ldap 1.10alpha3. This is because they include @DEFS@ on the command-line, which causes gcc to barf with a message saying -c and -o are incompatible for multiple compilations. The following patch remedies this: *** Makefile.pre.in~ Sun Jul 13 03:10:42 2003 --- Makefile.pre.in Tue Jul 29 18:23:22 2003 *************** *** 55,60 **** --- 55,61 ---- # Compiler options OPT= @OPT@ BASECFLAGS= @BASECFLAGS@ + DEFS= $(BASECFLAGS) CFLAGS= $(BASECFLAGS) $(OPT) CPPFLAGS= -I. -I$(srcdir)/Include LDFLAGS= @LDFLAGS@ (I am not sure if BASECFLAGS is a strict equivalent for DEFS, though). Platform: Solaris 8 MU7 x/86 Compiler: gcc-2.95.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779973&group_id=5470 From noreply@sourceforge.net Wed Jul 30 03:05:12 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 19:05:12 -0700 Subject: [Python-bugs-list] [ python-Bugs-779976 ] docs missing 'trace' module Message-ID: Bugs item #779976, was opened at 2003-07-29 20: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=779976&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) 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. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779976&group_id=5470 From noreply@sourceforge.net Wed Jul 30 04:30:05 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 20:30:05 -0700 Subject: [Python-bugs-list] [ python-Bugs-779999 ] PackageManager PIL-1.1.4-source not building Message-ID: Bugs item #779999, was opened at 2003-07-30 13: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=779999&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager PIL-1.1.4-source not building Initial Comment: PIL won't build without _tkinter support (looks like a bug in setup.py), so this dependancy needs to be added to PIL-1.1.4-source After installing _tkinter, PIL-source still dies with: gcc -Wl,-x -Wl,-F. -bundle -framework Python build/ temp.darwin-6.6-Power_Macintosh-2.3/_imagingtk.o build/ temp.darwin-6.6-Power_Macintosh-2.3/Tk/tkImaging.o - LlibImaging - -lImaging -o build/lib.darwin-6.6- Power_Macintosh-2.3/_imagingtk.so ld: Undefined symbols: _Tcl_AppendResult _Tcl_CreateCommand _Tk_FindPhoto _Tk_PhotoBlank _Tk_PhotoPutBlock_NoComposite error: command 'gcc' failed with exit status 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779999&group_id=5470 From noreply@sourceforge.net Wed Jul 30 07:26:48 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 23:26:48 -0700 Subject: [Python-bugs-list] [ python-Bugs-780024 ] Makefile.pre.in ignores CPPFLAGS from environment Message-ID: Bugs item #780024, was opened at 2003-07-30 00: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=780024&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bryan Blackburn (blb) Assigned to: Nobody/Anonymous (nobody) Summary: Makefile.pre.in ignores CPPFLAGS from environment Initial Comment: Makefile.pre.in doesnt use @CPPFLAGS@ when defining its own version, so if it is set in the environment while running configure, that setting is lost during the build. The following patch fixes this: --- Makefile.pre.in.orig Sun Jul 13 04:10:42 2003 +++ Makefile.pre.in Tue Jul 29 23:18:01 2003 @@ -56,7 +56,7 @@ OPT= @OPT@ BASECFLAGS= @BASECFLAGS@ CFLAGS= $(BASECFLAGS) $(OPT) -CPPFLAGS= -I. -I$(srcdir)/Include +CPPFLAGS= @CPPFLAGS@ -I. -I$(srcdir)/Include LDFLAGS= @LDFLAGS@ LDLAST= @LDLAST@ SGI_ABI= @SGI_ABI@ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780024&group_id=5470 From noreply@sourceforge.net Wed Jul 30 07:54:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Tue, 29 Jul 2003 23:54:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-779469 ] slices section in "what's new" has invalid example code Message-ID: Bugs item #779469, was opened at 2003-07-29 04:28 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779469&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David Fraser (davidfraser) >Assigned to: A.M. Kuchling (akuchling) Summary: slices section in "what's new" has invalid example code Initial Comment: In section 15 of the What's New docs for Python 2.3c2 (on extended slices for builtin types), the last example has this line: return FakeSeq([self.calc_item(i) in range(*indices)]) which should surely read: return FakeSeq([self.calc_item(i) for i in range(*indices)]) http://www.python.org/doc/2.3c2/whatsnew/section-slices.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779469&group_id=5470 From noreply@sourceforge.net Wed Jul 30 12:57:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 04:57:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-779469 ] slices section in "what's new" has invalid example code Message-ID: Bugs item #779469, was opened at 2003-07-29 05:28 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779469&group_id=5470 Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: A.M. Kuchling (akuchling) Summary: slices section in "what's new" has invalid example code Initial Comment: In section 15 of the What's New docs for Python 2.3c2 (on extended slices for builtin types), the last example has this line: return FakeSeq([self.calc_item(i) in range(*indices)]) which should surely read: return FakeSeq([self.calc_item(i) for i in range(*indices)]) http://www.python.org/doc/2.3c2/whatsnew/section-slices.html ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2003-07-30 07:57 Message: Logged In: YES user_id=11375 Fixed in CVS; thanks for spotting this! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779469&group_id=5470 From noreply@sourceforge.net Wed Jul 30 13:02:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 05:02:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-776602 ] readline should be in PackageManager database Message-ID: Bugs item #776602, was opened at 2003-07-24 01:58 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776602&group_id=5470 Category: Macintosh Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Jack Jansen (jackjansen) Summary: readline should be in PackageManager database Initial Comment: http://undefined.org/~bob/readline-0.0.1.tgz is a source installation of the readline module that downloads readline from gnu.org, compiles a static readline, and links Python with it.. therefore it does not depend on fink or a developer tools installation. A binary installer could easily be created using this. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-30 14:02 Message: Logged In: YES user_id=45365 It is now. I took your readline-0.0.1, replaced readline.c with the official 2.3 one, renamed the whole thing to "readline-2.3" and added it to PackMan in both source and binary form. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776602&group_id=5470 From noreply@sourceforge.net Wed Jul 30 13:11:31 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 05:11:31 -0700 Subject: [Python-bugs-list] [ python-Bugs-779999 ] PackageManager PIL-1.1.4-source not building Message-ID: Bugs item #779999, was opened at 2003-07-30 05:30 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779999&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager PIL-1.1.4-source not building Initial Comment: PIL won't build without _tkinter support (looks like a bug in setup.py), so this dependancy needs to be added to PIL-1.1.4-source After installing _tkinter, PIL-source still dies with: gcc -Wl,-x -Wl,-F. -bundle -framework Python build/ temp.darwin-6.6-Power_Macintosh-2.3/_imagingtk.o build/ temp.darwin-6.6-Power_Macintosh-2.3/Tk/tkImaging.o - LlibImaging - -lImaging -o build/lib.darwin-6.6- Power_Macintosh-2.3/_imagingtk.so ld: Undefined symbols: _Tcl_AppendResult _Tcl_CreateCommand _Tk_FindPhoto _Tk_PhotoBlank _Tk_PhotoPutBlock_NoComposite error: command 'gcc' failed with exit status 1 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-30 14:11 Message: Logged In: YES user_id=45365 I think the problem may be that you have some parts of Tkinter/ _tkinter/Tcl/Tk installed, and some not. (In other words: for me everything works fine, either with fink or without). Could you run the following commands from the Terminal, and attach the transcript to this bug report, please? (pimp.py is in Lib/ plat-mac, by the way). % ls -l /Library/Frameworks % ls -ld /sw % python pimp.py -vs % python pimp.py -iv PIL-1.1.4-source ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779999&group_id=5470 From noreply@sourceforge.net Wed Jul 30 13:21:57 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 05:21:57 -0700 Subject: [Python-bugs-list] [ python-Bugs-779999 ] PackageManager PIL-1.1.4-source not building Message-ID: Bugs item #779999, was opened at 2003-07-30 05:30 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779999&group_id=5470 Category: Macintosh Group: Platform-specific Status: Open Resolution: None Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager PIL-1.1.4-source not building Initial Comment: PIL won't build without _tkinter support (looks like a bug in setup.py), so this dependancy needs to be added to PIL-1.1.4-source After installing _tkinter, PIL-source still dies with: gcc -Wl,-x -Wl,-F. -bundle -framework Python build/ temp.darwin-6.6-Power_Macintosh-2.3/_imagingtk.o build/ temp.darwin-6.6-Power_Macintosh-2.3/Tk/tkImaging.o - LlibImaging - -lImaging -o build/lib.darwin-6.6- Power_Macintosh-2.3/_imagingtk.so ld: Undefined symbols: _Tcl_AppendResult _Tcl_CreateCommand _Tk_FindPhoto _Tk_PhotoBlank _Tk_PhotoPutBlock_NoComposite error: command 'gcc' failed with exit status 1 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-30 14:21 Message: Logged In: YES user_id=45365 Sorry, ignore my request for more information. I knew already about this problem. I'm working on it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-30 14:11 Message: Logged In: YES user_id=45365 I think the problem may be that you have some parts of Tkinter/ _tkinter/Tcl/Tk installed, and some not. (In other words: for me everything works fine, either with fink or without). Could you run the following commands from the Terminal, and attach the transcript to this bug report, please? (pimp.py is in Lib/ plat-mac, by the way). % ls -l /Library/Frameworks % ls -ld /sw % python pimp.py -vs % python pimp.py -iv PIL-1.1.4-source ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779999&group_id=5470 From noreply@sourceforge.net Wed Jul 30 14:08:39 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 06:08:39 -0700 Subject: [Python-bugs-list] [ python-Bugs-780203 ] Tkinter failure in 2.3 under Windows Message-ID: Bugs item #780203, was opened at 2003-07-30 13: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=780203&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter failure in 2.3 under Windows Initial Comment: I have a Tkinter program which no longer works after installing Python 2.3 under Windows 98. Traceback (most recent call last): File "C:\home\tim\python\boggle.py", line 1386, in ? define_widgets() File "C:\home\tim\python\boggle.py", line 1123, in define_widgets frame1.grid(row=0, col=0,padx=20,pady=20) File "C:\PYTHON23\lib\lib-tk\Tkinter.py", line 1763, in grid_configure self.tk.call( TclError: ambiguous option "-col": must be -column, -columnspan, -in, -ipadx, -ipa dy, -padx, -pady, -row, -rowspan, or -sticky It worked in Python 2.2 under Windows and it works in Python 2.3 under Linux. Tim ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780203&group_id=5470 From noreply@sourceforge.net Wed Jul 30 14:54:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 06:54:13 -0700 Subject: [Python-bugs-list] [ python-Bugs-780203 ] Tkinter failure in 2.3 under Windows Message-ID: Bugs item #780203, was opened at 2003-07-30 09: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=780203&group_id=5470 Category: Tkinter Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter failure in 2.3 under Windows Initial Comment: I have a Tkinter program which no longer works after installing Python 2.3 under Windows 98. Traceback (most recent call last): File "C:\home\tim\python\boggle.py", line 1386, in ? define_widgets() File "C:\home\tim\python\boggle.py", line 1123, in define_widgets frame1.grid(row=0, col=0,padx=20,pady=20) File "C:\PYTHON23\lib\lib-tk\Tkinter.py", line 1763, in grid_configure self.tk.call( TclError: ambiguous option "-col": must be -column, -columnspan, -in, -ipadx, -ipa dy, -padx, -pady, -row, -rowspan, or -sticky It worked in Python 2.2 under Windows and it works in Python 2.3 under Linux. Tim ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-30 09:54 Message: Logged In: YES user_id=31435 Which version of Tcl/Tk are you using on Linux? The Windows 2.3 ships with 8.4.3, the most-recent available at the time of the 2.3 release. From the error msg, it seems pretty obvious that 8.4.3 can't figure out whether "col" was intended to mean "column" or "columnspan". Maybe Tk 8.4.3 added one of those options. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780203&group_id=5470 From noreply@sourceforge.net Wed Jul 30 14:58:47 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 06:58:47 -0700 Subject: [Python-bugs-list] [ python-Bugs-780231 ] Bug in "Build and C API Changes" section of what's new doc? Message-ID: Bugs item #780231, was opened at 2003-07-30 21:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780231&group_id=5470 Category: Documentation Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in "Build and C API Changes" section of what's new doc? Initial Comment: I think there is a bug in the "Build and C API Changes" section of the "what's new in 2.3" document: http://www.python.org/doc/2.3/whatsnew/node20.html It lists a set of changes to the garbage collection C API, but the changes mentioned look like the ones made in Python 2.2a3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780231&group_id=5470 From noreply@sourceforge.net Wed Jul 30 16:14:23 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 08:14:23 -0700 Subject: [Python-bugs-list] [ python-Bugs-779999 ] PackageManager PIL-1.1.4-source not building Message-ID: Bugs item #779999, was opened at 2003-07-30 05:30 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779999&group_id=5470 Category: Macintosh Group: Platform-specific >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stuart Bishop (zenzen) Assigned to: Jack Jansen (jackjansen) Summary: PackageManager PIL-1.1.4-source not building Initial Comment: PIL won't build without _tkinter support (looks like a bug in setup.py), so this dependancy needs to be added to PIL-1.1.4-source After installing _tkinter, PIL-source still dies with: gcc -Wl,-x -Wl,-F. -bundle -framework Python build/ temp.darwin-6.6-Power_Macintosh-2.3/_imagingtk.o build/ temp.darwin-6.6-Power_Macintosh-2.3/Tk/tkImaging.o - LlibImaging - -lImaging -o build/lib.darwin-6.6- Power_Macintosh-2.3/_imagingtk.so ld: Undefined symbols: _Tcl_AppendResult _Tcl_CreateCommand _Tk_FindPhoto _Tk_PhotoBlank _Tk_PhotoPutBlock_NoComposite error: command 'gcc' failed with exit status 1 ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-30 17:14 Message: Logged In: YES user_id=45365 It turns out the bug in setup.py couldn't be worked around, so there is now a tarball specifically for PackageManager. I will send the diffs to /F. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-30 14:21 Message: Logged In: YES user_id=45365 Sorry, ignore my request for more information. I knew already about this problem. I'm working on it. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-30 14:11 Message: Logged In: YES user_id=45365 I think the problem may be that you have some parts of Tkinter/ _tkinter/Tcl/Tk installed, and some not. (In other words: for me everything works fine, either with fink or without). Could you run the following commands from the Terminal, and attach the transcript to this bug report, please? (pimp.py is in Lib/ plat-mac, by the way). % ls -l /Library/Frameworks % ls -ld /sw % python pimp.py -vs % python pimp.py -iv PIL-1.1.4-source ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779999&group_id=5470 From noreply@sourceforge.net Wed Jul 30 16:35:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 08:35:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-780300 ] pyexpat LexicalHandler swaps system_id and public_id Message-ID: Bugs item #780300, was opened at 2003-07-30 15:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780300&group_id=5470 Category: XML Group: Python 2.2.3 Status: Open Resolution: None Priority: 5 Submitted By: Holger Floerke (floerke) Assigned to: Nobody/Anonymous (nobody) Summary: pyexpat LexicalHandler swaps system_id and public_id Initial Comment: XML: test DTD: you can imagine ... ch = MyHandler() parser = make_parser() parser.setProperty(handler.property_lexical_handler, ch) ... class MyHandler(XMLGenerator): ... def startDTD(self, name, public_id, system_id): self._out.write(public_id) ... -> "a.dtd" (but a.dtd should be the system_id) and the system_id in method startDTD is None a glimpse into pyexpat.c from python 2.2.3 ... VOID_HANDLER(StartDoctypeDecl, ... STRING_CONV_FUNC,doctypeName, STRING_CONV_FUNC,sysid, STRING_CONV_FUNC,pubid, has_internal_subset)) ... maybe sysid and pubid is swapped. I'm not a python specialist and maybe this bug is fixed or is not a bug. Please let me know... HolgeR ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780300&group_id=5470 From noreply@sourceforge.net Wed Jul 30 17:11:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 09:11:15 -0700 Subject: [Python-bugs-list] [ python-Bugs-780315 ] something warning in random.py Message-ID: Bugs item #780315, was opened at 2003-07-30 16: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=780315&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: kyo (ky0) Assigned to: Nobody/Anonymous (nobody) Summary: something warning in random.py Initial Comment: c:\python23\lib\random.py:52: DeprecationWarning: classic float division NV_MAGICCONST = 4 * _exp(-0.5)/_sqrt(2.0) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780315&group_id=5470 From noreply@sourceforge.net Wed Jul 30 18:02:43 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 10:02:43 -0700 Subject: [Python-bugs-list] [ python-Bugs-780354 ] socket.makefile() isn't compatible with marshal/cPickle/etc Message-ID: Bugs item #780354, was opened at 2003-07-30 12:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: David M. Grimes (dmgrime) Assigned to: Nobody/Anonymous (nobody) Summary: socket.makefile() isn't compatible with marshal/cPickle/etc Initial Comment: Even on platforms where the underlying C libraries and associated code in socketmodule.c support it, socket object's .makefile() method no longer return "real" file objects. This breaks support for cPickle, marshal, and any other C modules which expect a file object as an argument. The change initially appears in socket.py v1.36 - the changelog entry states: """ The socket module now always uses the _socketobject wrapper class, even on platforms which have dup(2). The makefile() method is built directly on top of the socket without duplicating the file descriptor, allowing timeouts to work properly. Includes a new test case (urllibnet) which requires the network resource. Closes bug 707074. """ I'm not sure of the implication WRT timeouts, but the patch is very small - quite obviously removing the platform check which prevented the redefinition of the symbol socket in the exports of socket.py. It now is always the _socketobject class, and not the underlying _socket.socket type (when it is known the platform supports all functionality in _socket). For now, I can workaround (since I don't need the timeout semantics) by using _socket.socket() directly (I'm on a Linux platform), but I wondered if this is something which can/should be addressed differently? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780354&group_id=5470 From noreply@sourceforge.net Wed Jul 30 19:36:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 11:36:14 -0700 Subject: [Python-bugs-list] [ python-Bugs-780407 ] cast from pointer to integer of different size Message-ID: Bugs item #780407, was opened at 2003-07-30 18: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=780407&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: cast from pointer to integer of different size Initial Comment: this warning (gcc-3.2 or gcc-3.3) was introduced betwen 20030321 and 20030505, when compiling on 64bit targets gcc -c -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I../Include -DPy_BUILD_CORE -o Parser/grammar.o ../Parser/grammar.c ../Parser/grammar.c: In function `_Py_addlabel': ../Parser/grammar.c:107: warning: cast from pointer to integer of different size printf("Label @ %08x, %d: %s\n", (unsigned)ll, ... this should be casted to an unsigned long, and %lx format. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780407&group_id=5470 From noreply@sourceforge.net Wed Jul 30 20:57:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 12:57:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-215487 ] Windows installer not logo compliant Message-ID: Bugs item #215487, was opened at 2000-09-27 09:28 Message generated for change (Comment added) made by clumma You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215487&group_id=5470 Category: Windows Group: Feature Request Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Tim Peters (tim_one) Summary: Windows installer not logo compliant Initial Comment: Python 2.0b2 is not Windows 2000 Logo compliant. I noticed the following problems: Installer does not use the Microsoft Windows Installer Service [2.1] Installer does not install into "Program Files" by default [2.4] Installer does not create new Uninstall registry entries: [2.5] InstallLocation, Publisher, VersionMajor, VersionMinor Installer does not support advertising [2.6] IDLE does not default to My Documents when saving files [4.1] ---------------------------------------------------------------------- Comment By: Carl Lumma (clumma) Date: 2003-07-30 12:57 Message: Logged In: YES user_id=834100 The msi installer service is egregious. "Program Files" need not be default, for reasons explained in previous comment. But it *should* be supported, which it isn't in the 2.3 installer. I've created a new bug for this. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-27 12:10 Message: W2000 Logo compliance is a non-goal. Some of these may be nice (e.g., using MSI when available), others will never happen (installing into "Program Files" -- that (a path with an embedded space) is the dumbest conceivable place to install an app users want to run from a cmd line -- Python *used* to get installed there, and dealing with the space was a major barrier for newbies). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215487&group_id=5470 From noreply@sourceforge.net Wed Jul 30 21:20:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 13:20:50 -0700 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 (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None 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 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780461&group_id=5470 From noreply@sourceforge.net Wed Jul 30 22:36:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 14:36:28 -0700 Subject: [Python-bugs-list] [ python-Bugs-780315 ] DeprecationWarning in random.py Message-ID: Bugs item #780315, was opened at 2003-07-30 09:11 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780315&group_id=5470 Category: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: kyo (ky0) Assigned to: Nobody/Anonymous (nobody) >Summary: DeprecationWarning in random.py Initial Comment: c:\python23\lib\random.py:52: DeprecationWarning: classic float division NV_MAGICCONST = 4 * _exp(-0.5)/_sqrt(2.0) ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2003-07-30 14:36 Message: Logged In: YES user_id=357491 The only way to reproduce this is to be running the interpreter with the -Qwarnall option; ``./python.exe -Qwarnall -c "import random"`` will reproduce it. But if you run ``./python.exe -Qnew -c "import random" `` everything is fine. All of this has to do with true division that will become the default in Python 3. -Qwarnall warns about *all* division, even when the mathematical outcome of the division is the same regardless of whether ``from __future__ import division`` (which can also be done on the command-line by passing the -Qnew option) was run or not. In other words there is nothing to worry about here. I am closing this as "won't fix". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780315&group_id=5470 From noreply@sourceforge.net Wed Jul 30 23:09:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 15:09:58 -0700 Subject: [Python-bugs-list] [ python-Bugs-780203 ] Tkinter failure in 2.3 under Windows Message-ID: Bugs item #780203, was opened at 2003-07-30 09:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780203&group_id=5470 Category: Tkinter >Group: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: Tkinter failure in 2.3 under Windows Initial Comment: I have a Tkinter program which no longer works after installing Python 2.3 under Windows 98. Traceback (most recent call last): File "C:\home\tim\python\boggle.py", line 1386, in ? define_widgets() File "C:\home\tim\python\boggle.py", line 1123, in define_widgets frame1.grid(row=0, col=0,padx=20,pady=20) File "C:\PYTHON23\lib\lib-tk\Tkinter.py", line 1763, in grid_configure self.tk.call( TclError: ambiguous option "-col": must be -column, -columnspan, -in, -ipadx, -ipa dy, -padx, -pady, -row, -rowspan, or -sticky It worked in Python 2.2 under Windows and it works in Python 2.3 under Linux. Tim ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2003-07-30 18:09 Message: Logged In: YES user_id=33168 This is due to the use of Tk 8.4. col must be changed to column. In Tk versions up to 8.3, col was an alias for column, but that apparently changed in 8.4. I'm closing this as invalid, since this is really a Tk issue. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-30 09:54 Message: Logged In: YES user_id=31435 Which version of Tcl/Tk are you using on Linux? The Windows 2.3 ships with 8.4.3, the most-recent available at the time of the 2.3 release. From the error msg, it seems pretty obvious that 8.4.3 can't figure out whether "col" was intended to mean "column" or "columnspan". Maybe Tk 8.4.3 added one of those options. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780203&group_id=5470 From noreply@sourceforge.net Thu Jul 31 00:05:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 16:05:10 -0700 Subject: [Python-bugs-list] [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-30 18: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=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply@sourceforge.net Thu Jul 31 01:14:58 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 17:14:58 -0700 Subject: [Python-bugs-list] [ python-Feature Requests-780602 ] No sleep or busy wait Message-ID: Feature Requests item #780602, was opened at 2003-07-30 19:14 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=780602&group_id=5470 Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Nobody/Anonymous (nobody) Summary: No sleep or busy wait Initial Comment: This is a request for three, related changes to file Modules/_tkinter.c in Python 2.3, specifically to avoid sleeping or busy waiting. 1) The main loop, function Tkapp_Mainloop(), includes a now configurable sleep period which may cause undesirable delays (in the threaded builds). If no Tcl/Tk event was handled, the main loop sleeps for 20 millisec (or whatever the value of Tkinter_busywaitinterval* is). Another, better way to achieve that would be to create a timer event for in the main loop BEFORE calling the Tcl/Tk event handler and call the Tcl/Tk event handler with a zero argument to wait for an event**. This produces the same idle period as the current implementation. The difference is that the main loop (actually the Tcl/Tk event handler) stays awake instead of going to sleep for the idle period. Any events occurring during the idle period will be handled without delay. 2) In addition, only one event is handled per iteration of the main loop, causing the state to be saved and restored, locks to be acquired and releases, etc. many times. Instead handle not one event, but all pending events. After handling one event, all other pending events should be handled as well by calling the Tcl/Tk event handler again (with a TCL_DONT_WAIT argument) until there are no more events. The net result is that any pending events are handled more quickly and with less overhead. 3) After the first change abiove, static function Sleep() can be removed. It is still needed in function WaitForMainloop() but that call can be replaced by Tcl_Sleep(). Tcl_Sleep() is equivalent to Sleep() and it works on all platforms, not just those which have select(). -------- *) The name Tkinter_busywaitinterval is a misnomer. It is not a busy wait but a non-buzy sleep, at least with Tcl_Sleep(). **) There are a few more details to make this work correctly and I have a version for _tkinter.c which does implement these changes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=780602&group_id=5470 From noreply@sourceforge.net Thu Jul 31 03:27:44 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 19:27:44 -0700 Subject: [Python-bugs-list] [ python-Bugs-780638 ] IDLE won't run on Win2K Message-ID: Bugs item #780638, was opened at 2003-07-31 02: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=780638&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kellie Miller (javajini) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE won't run on Win2K Initial Comment: When I noticed that Python 2.3 was out today I downloaded it immediately! I uninstalled 2.2.3 and installed 2.3. When I tried to start IDLE the cursor changed to the hour glass momentarily and then back to the arrow. When I tried running IDLE from cmd.exe I got the shell prompt immediately. IDLE worked fine under 2.2.3. I am running on a DELL Latitude C600 with Windows 2000 5.00.2195 Service Pack 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780638&group_id=5470 From noreply@sourceforge.net Thu Jul 31 04:06:30 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Wed, 30 Jul 2003 20:06:30 -0700 Subject: [Python-bugs-list] [ python-Bugs-780638 ] IDLE won't run on Win2K Message-ID: Bugs item #780638, was opened at 2003-07-30 22:27 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780638&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Kellie Miller (javajini) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE won't run on Win2K Initial Comment: When I noticed that Python 2.3 was out today I downloaded it immediately! I uninstalled 2.2.3 and installed 2.3. When I tried to start IDLE the cursor changed to the hour glass momentarily and then back to the arrow. When I tried running IDLE from cmd.exe I got the shell prompt immediately. IDLE worked fine under 2.2.3. I am running on a DELL Latitude C600 with Windows 2000 5.00.2195 Service Pack 2. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2003-07-30 23:06 Message: Logged In: YES user_id=31435 2.3's IDLE works fine on my Win2K. What happens when you try the following from a DOS box? C:\Python23>python Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter >>> Tkinter._test() >>> That will tell us whether Tk is working. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780638&group_id=5470 From noreply@sourceforge.net Thu Jul 31 09:37:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 01:37:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-780714 ] infinite __str__ recursion in thread causes seg fault Message-ID: Bugs item #780714, was opened at 2003-07-31 08: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=780714&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Gregory (stefan_gregory) Assigned to: Nobody/Anonymous (nobody) Summary: infinite __str__ recursion in thread causes seg fault Initial Comment: The following code reliably produces a segmentation fault under Solaris8 in Python2.3, Python2.2, Python2.1.3 and Python1.5. It produces a Bus Error when run on Python2.2 under OSX. Clearly it should produce a Python RuntimeError. import thread, time class Frog: def __str__(self): return str(self) f = Frog() thread.start_new_thread(str,(f,)) time.sleep(1000) This problem manifests in scenarios such as when you have 2 publishing objects (such as HTMLgen objects) A and B and you put A inside B and B inside A and each objects __str__ method calls its childrens __str__ methods and voila! (I hope this might be the reason my Zope server has been intermitently crashing for the past year or so though I have not found any recursive structures yet.) With Python2.3 gdb reports: vgetargskeywords (args=0x1bdaf0, keywords=0x0, format=0xd2579 "0:str", kwlist=0xf7b4c, p_va=0xfed0C02c) at Python/getargs.c:1167 Though with Python2.1 it dies at line 330 in getargs.c. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 From noreply@sourceforge.net Thu Jul 31 10:11:29 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 02:11:29 -0700 Subject: [Python-bugs-list] [ python-Bugs-780725 ] Compile error messages and PEP-263 Message-ID: Bugs item #780725, was opened at 2003-07-31 18: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=780725&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: Compile error messages and PEP-263 Initial Comment: If a source file contains encoding definition and it has syntax errors, Python prints line of source file in utf-8. Here's simple example. # -*- coding: Shift_JIS -*- print "XXXXX" abcdefg # "XXXXX" is Japanese ShiftJIS string. With this source file, Python prints a second line as a part of error message in utf-8 encoding. Lines printed here should be reconverted into original encoding. Also, error column that '^' character marks is wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780725&group_id=5470 From noreply@sourceforge.net Thu Jul 31 10:16:56 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 02:16:56 -0700 Subject: [Python-bugs-list] [ python-Bugs-780730 ] PEP-263 and 278 Message-ID: Bugs item #780730, was opened at 2003-07-31 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=780730&group_id=5470 Category: Parser/Compiler Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: PEP-263 and 278 Initial Comment: Universal Newline Support doesn't work for source files that contain encoding definition. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780730&group_id=5470 From noreply@sourceforge.net Thu Jul 31 11:27:18 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 03:27:18 -0700 Subject: [Python-bugs-list] [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-31 00:04 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2003-07-31 11:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply@sourceforge.net Thu Jul 31 13:17:26 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 05:17:26 -0700 Subject: [Python-bugs-list] [ python-Bugs-780807 ] time.strptime() 1,200 times slower in python2.3 Message-ID: Bugs item #780807, was opened at 2003-07-31 12:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Malte John (drmalte) Assigned to: Nobody/Anonymous (nobody) Summary: time.strptime() 1,200 times slower in python2.3 Initial Comment: time.strptime() ist about 1,200 (onethousand and twohundred) times slower in 2.3 than in 2.2! (1m:48.45s vs. 0.09s) This is caused by the pure python implementation. Fix: I simply repaced the function time_strptime(PyObject *self, PyObject *args) from Python-2.3/Modules/timemodule.c with the function from python 2.2. Maybe 'configure' should check for existence of the strptime() function on the target system and use it, if available? Regards, Malte ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780807&group_id=5470 From noreply@sourceforge.net Thu Jul 31 15:22:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 07:22:19 -0700 Subject: [Python-bugs-list] [ python-Bugs-467924 ] Improve the ZipFile Interface Message-ID: Bugs item #467924, was opened at 2001-10-04 11:54 Message generated for change (Comment added) made by mzimmerman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=467924&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Improve the ZipFile Interface Initial Comment: There exist two methods to write to a ZipFile write(self, filename, arcname=None, compress_type=None) writestr(self, zinfo, bytes) but only one to read from it read(self, name) Additionally, the two 'write's behave differently with respect to compression. --- (a) 'read' does not fit to 'write', since 'write' takes a file and adds it to a ZipFile, but 'read' is not the reverse operation. 'read' should be called 'readstr' since it much better matches to 'writestr'. (b) It is confusing what 'write' and 'read' actually mean. Does 'write' write a file, or into the ZipFile? It would be more obvious if ZipFile has 4 methods which pair-wise fit together: writestr (self, zinfo, bytes) # same as now readstr (self, name) # returns bytes (as string), currently called 'read' # 'read' could still live but should be deprecated add (self, filename, arcname=None, compress_type=None) # currently 'write' # 'write' could still live but should be deprecated extract (self, name, filename, arcname=None) # new, desired functionality (c) BOTH, 'writestr' and 'add' should by default use the 'compress_type' that was passed to the constructor of 'ZipFile'. Currently, 'write' does it, 'writestr' via zinfo does it not. 'ZipInfo' sets the compression strict to 'ZIP_STORED' :-( It should not do that! It rather should: - allow more parameters in the signature of the constructor to also pass the compression type (and some other attributes, too) - default to 'None', so that 'writestr' can see this, and then take the default from the 'ZipFile' instance. ---------------------------------------------------------------------- Comment By: Matt Zimmerman (mzimmerman) Date: 2003-07-31 10:22 Message: Logged In: YES user_id=196786 It would also be very useful to be able to have ZipFile read/write the uncompressed file data from/to a file-like object, instead of just strings and files (respectively). I would like to use this module to work with zip files containing large files, but this is unworkable because the current implementation would use excessive amounts of memory. Currently, read() reads all of the compressed data into memory, then uncompresses it into memory. For files which may be hundreds of megabytes compressed, this is undesirable. Likewise for write(), I would like to be able to stream data into a zip file, passing in a ZipInfo to specify the metadata as is done with writestr(). The implementation of this functionality is quite straightforward, but I am not sure whether (or how) the interface should change. Some other parts of the library allow for a file object to be passed to the same interface which accepts a filename. The object is examined to see if it has the necessary read/write methods and if not, it is assumed to be a filename. Would this be the correct way to do it? I, too, am a bit irked by the lack of symmetry exhibited by read vs. write/writestr, and think that the interface suggested above would be a significant improvement. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2003-01-05 15:54 Message: Logged In: YES user_id=92689 In Python 2.3, writestr() has an enhanced signature: the first arg may now also be an archive name, in which case the correct default settings are used (ie. the compression value is taken from the file). See patch #651621. extract() could be moderately useful (although I don't understand the 'arcname' arg, how's that different from 'name'?) but would have to deal with file modes (bin/text). The file mode isn't in the archive so would have to (optionally) be supplied by the caller. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=467924&group_id=5470 From noreply@sourceforge.net Thu Jul 31 15:48:09 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 07:48:09 -0700 Subject: [Python-bugs-list] [ python-Bugs-780887 ] recent-files defaulted to strange place and bad permissions Message-ID: Bugs item #780887, was opened at 2003-07-31 10: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=780887&group_id=5470 Category: IDLE Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Lloyd Hugh Allen (lha2) Assigned to: Nobody/Anonymous (nobody) Summary: recent-files defaulted to strange place and bad permissions Initial Comment: After a non-admin install of Python 2.3 with Python 2.2 admin-installed, I got: C:\Python23\Lib\idlelib>c:\python23\python idle.py Traceback (most recent call last): File "idle.py", line 23, in ? idlelib.PyShell.main() File "C:\Python23\lib\idlelib\PyShell.py", line 1277, in main flist.pyshell = PyShell(flist) File "C:\Python23\lib\idlelib\PyShell.py", line 721, in __init__ OutputWindow.__init__(self, flist, None, None) File "C:\Python23\lib\idlelib\OutputWindow.py", line 16, in __init__ EditorWindow.__init__(self, *args) File "C:\Python23\lib\idlelib\EditorWindow.py", line 181, in __init__ self.UpdateRecentFilesList() File "C:\Python23\lib\idlelib\EditorWindow.py", line 580, in UpdateRecentFilesList RFfile=open(self.recentFilesPath,'r') IOError: [Errno13] Permission denied: 'F:\.idlerc\recent- files.lst' ====== I have a login to a university server, and the F drive is the user drive. I don't recall specifying that anything should be kept on the F drive, and would prefer that recent files be kept on the local machine. Changing my own permissions to .idlerc to allow full permissions, and to apply these permissions to contents, worked and resolved the problem, except that multiple users use the same network drive and will now share recent files. Idle 1.0 under the brand-spanking-new Python2.3, with Windows XP Professional 5.1.2600 Service Pack 1 Build 2600. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780887&group_id=5470 From noreply@sourceforge.net Thu Jul 31 16:38:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 08:38:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-780638 ] IDLE won't run on Win2K Message-ID: Bugs item #780638, was opened at 2003-07-31 02:27 Message generated for change (Comment added) made by javajini You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780638&group_id=5470 Category: IDLE Group: Python 2.3 >Status: Closed Resolution: None Priority: 5 Submitted By: Kellie Miller (javajini) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE won't run on Win2K Initial Comment: When I noticed that Python 2.3 was out today I downloaded it immediately! I uninstalled 2.2.3 and installed 2.3. When I tried to start IDLE the cursor changed to the hour glass momentarily and then back to the arrow. When I tried running IDLE from cmd.exe I got the shell prompt immediately. IDLE worked fine under 2.2.3. I am running on a DELL Latitude C600 with Windows 2000 5.00.2195 Service Pack 2. ---------------------------------------------------------------------- >Comment By: Kellie Miller (javajini) Date: 2003-07-31 15:38 Message: Logged In: YES user_id=6557 I discovered this was due to a conflict between the version of TCL that I had installed for Ruby and the one required for Python. When I deleted the environment variable that pointed to the Ruby copy of the TCL dll, Python came up fine. Thanks to Tim Peters for helping me figure this one out. Kellie ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-07-31 03:06 Message: Logged In: YES user_id=31435 2.3's IDLE works fine on my Win2K. What happens when you try the following from a DOS box? C:\Python23>python Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter >>> Tkinter._test() >>> That will tell us whether Tk is working. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780638&group_id=5470 From noreply@sourceforge.net Thu Jul 31 17:30:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 09:30:52 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 07:35 Message generated for change (Comment added) made by thelinuxduck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- Comment By: The LinuxDuck (thelinuxduck) Date: 2003-07-31 11:30 Message: Logged In: YES user_id=490655 Just a comment.. I was experimenting with ways to make the test pass (slack 8.1, glib 2.1.3, gcc 3.0.2), and by telling it to test tzname[1] with "AEST" it will pass (though I'm sure this violates whatever the test is for in the first place), but it fails on the time.daylight test (daylight = 0 when should = 1). Interestingly enough, if I change: test_time.py:103: environ['TZ'] = victoria to test_time.py:103: environ['TZ'] = 'Australia/Victoria' (as per the 'time' module documentation) it fails the same way, except the tztime[0,1] = EST,EST instead of AEST,*AEST (*as is the cause for the failed test in the first place). Bear in mind I know jack diddly about how the timezone stuff works, so I'm just playing, and thought I'd share my results.. (= ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 22:38 Message: Logged In: YES user_id=12800 I'm not sure there's anything we can do about this for Python 2.3 final. Lowering the priority, although I will add a note in known bugs.html page. ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2003-07-27 18:04 Message: Logged In: YES user_id=827666 Hi. I just thought I'd mention that I got the same results with 2.3c2. Tim ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2003-07-21 22:09 Message: Logged In: YES user_id=827666 Hello. I just downloaded 2.3c1. I failed test_time as well. I was going to submit a new bug, but then I saw this thread. I hope this is the right place. test_time test test_time failed -- Traceback (most recent call last): File "/home/tim/Download/Python-2.3c1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/tim/Download/Python-2.3c1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST 227 tests OK. 1 test failed: test_time 27 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_email_codecs test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on linux2. make: *** [test] Error 1 For what it's worth, time seems to work... $ ./python -c 'import time; print time.tzname' ('EST', 'EDT') $ cat /proc/version Linux version 2.4.20 (root@mrbun) (gcc version 2.95.3 20010315 (release)) #11 Sat Nov 30 05:52:58 EST 2002 Tim ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-12 21:28 Message: Logged In: YES user_id=357491 I uploaded a new version of the patch. Give it a try and see what happens if you could. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-10 12:11 Message: Logged In: YES user_id=357491 Barry says you need to do the following to truly test the patch: - check out the head - make distclean - apply the patch - autoreconf - ./configure --with-pydebug - make test Apparently autoreconf regenerates something for autoconf and that has to be done. Learn something new everyday. Can you give that a shot, Torsten? If that still fails it is going to take some work to figure this one out. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-10 02:58 Message: Logged In: YES user_id=269193 no, sorry, no success! * re-compiled python, as expected the test failed again. * patch -p0 <../tzset4.diff * made a "make distclean" * ./configure again, looked nice, no chached stuff. * make * make test >>> failed again !!! anything i could check to help? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 23:37 Message: Logged In: YES user_id=80475 Tonight, test_time also failed for me and then worked on the next pass. Am using WinME and Py2.3b2+. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-09 13:30 Message: Logged In: YES user_id=269193 sorry, problem! hard drive scambled. i have to re-install python anyway. i will see if the test fails again, and then i try to apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 12:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 00:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 21:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 12:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 10:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Thu Jul 31 17:41:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 09:41:37 -0700 Subject: [Python-bugs-list] [ python-Bugs-763153 ] unit test test_time failed Message-ID: Bugs item #763153, was opened at 2003-06-30 07:35 Message generated for change (Comment added) made by thelinuxduck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 6 Submitted By: Torsten Will (towi) Assigned to: Brett Cannon (bcannon) Summary: unit test test_time failed Initial Comment: === ERROR MASSAGE === $ make test ... test test_time failed -- Traceback (most recent call last): File "/vol/tmp/Python-2.3b2/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/vol/tmp/Python-2.3b2/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST ... =========== SYSTEM =========== $ cat /proc/version Linux version 2.4.19 (root@haplo) (gcc version 2.95.3 20010315 (SuSE)) #4 SMP Tue Mar 4 09:23:24 CET 2003 ---------------------------------------------------------------------- Comment By: The LinuxDuck (thelinuxduck) Date: 2003-07-31 11:41 Message: Logged In: YES user_id=490655 Sorry to pollute here, but just an FYI: Setting line 103 to: environ['TZ'] = 'Australia/Victoria' and changing lines 106- 107 to: self.failUnless(time.tzname[0] == 'EST', str(time.tzname[0])) self.failUnless(time.tzname[1] == 'EST', str(time.tzname[1])) all subsequent tests pass just fine, and the module test completes successfully. Granted, I don't know what the difference between EST and EDT is, but it works. (= With line 103, setting environ['TZ'] as the var 'victoria' and setting line 107 to AEST, that test passes, but as I mentioned before, the time.daylight test fails. ---------------------------------------------------------------------- Comment By: The LinuxDuck (thelinuxduck) Date: 2003-07-31 11:30 Message: Logged In: YES user_id=490655 Just a comment.. I was experimenting with ways to make the test pass (slack 8.1, glib 2.1.3, gcc 3.0.2), and by telling it to test tzname[1] with "AEST" it will pass (though I'm sure this violates whatever the test is for in the first place), but it fails on the time.daylight test (daylight = 0 when should = 1). Interestingly enough, if I change: test_time.py:103: environ['TZ'] = victoria to test_time.py:103: environ['TZ'] = 'Australia/Victoria' (as per the 'time' module documentation) it fails the same way, except the tztime[0,1] = EST,EST instead of AEST,*AEST (*as is the cause for the failed test in the first place). Bear in mind I know jack diddly about how the timezone stuff works, so I'm just playing, and thought I'd share my results.. (= ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-07-28 22:38 Message: Logged In: YES user_id=12800 I'm not sure there's anything we can do about this for Python 2.3 final. Lowering the priority, although I will add a note in known bugs.html page. ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2003-07-27 18:04 Message: Logged In: YES user_id=827666 Hi. I just thought I'd mention that I got the same results with 2.3c2. Tim ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2003-07-21 22:09 Message: Logged In: YES user_id=827666 Hello. I just downloaded 2.3c1. I failed test_time as well. I was going to submit a new bug, but then I saw this thread. I hope this is the right place. test_time test test_time failed -- Traceback (most recent call last): File "/home/tim/Download/Python-2.3c1/Lib/test/test_time.py", line 107, in test_tzset self.failUnless(time.tzname[1] == 'AEDT', str(time.tzname[1])) File "/home/tim/Download/Python-2.3c1/Lib/unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: AEST 227 tests OK. 1 test failed: test_time 27 tests skipped: test_aepack test_al test_bsddb185 test_bsddb3 test_cd test_cl test_curses test_email_codecs test_gl test_imgfile test_linuxaudiodev test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_timeout test_unicode_file test_urllibnet test_winreg test_winsound Those skips are all expected on linux2. make: *** [test] Error 1 For what it's worth, time seems to work... $ ./python -c 'import time; print time.tzname' ('EST', 'EDT') $ cat /proc/version Linux version 2.4.20 (root@mrbun) (gcc version 2.95.3 20010315 (release)) #11 Sat Nov 30 05:52:58 EST 2002 Tim ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-12 21:28 Message: Logged In: YES user_id=357491 I uploaded a new version of the patch. Give it a try and see what happens if you could. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-10 12:11 Message: Logged In: YES user_id=357491 Barry says you need to do the following to truly test the patch: - check out the head - make distclean - apply the patch - autoreconf - ./configure --with-pydebug - make test Apparently autoreconf regenerates something for autoconf and that has to be done. Learn something new everyday. Can you give that a shot, Torsten? If that still fails it is going to take some work to figure this one out. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-10 02:58 Message: Logged In: YES user_id=269193 no, sorry, no success! * re-compiled python, as expected the test failed again. * patch -p0 <../tzset4.diff * made a "make distclean" * ./configure again, looked nice, no chached stuff. * make * make test >>> failed again !!! anything i could check to help? ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-07-09 23:37 Message: Logged In: YES user_id=80475 Tonight, test_time also failed for me and then worked on the next pass. Am using WinME and Py2.3b2+. ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-07-09 13:30 Message: Logged In: YES user_id=269193 sorry, problem! hard drive scambled. i have to re-install python anyway. i will see if the test fails again, and then i try to apply the patch. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-09 12:15 Message: Logged In: YES user_id=357491 Torsten, can you please try the patch that Neal pointed out? We are approaching the release of Python 2.3 (by the end of the month) and it would be nice if this bug was settled before it goes out. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-07-01 00:10 Message: Logged In: YES user_id=357491 If you are referring to bug #763047 and its cohort #763052, then no, I don't think so. Those I think were an actual bug in the code. But there *is* a possibility since _strptime does call time.tzset when it calculates what timezones it knows about. I am unassigning from myself since I have never touched time.tzset (don't remember who wrote time.tzset off the top of my head but it is a Python 2.3 feature). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-30 21:38 Message: Logged In: YES user_id=80475 Brett, is this related to the other failures? ---------------------------------------------------------------------- Comment By: Torsten Will (towi) Date: 2003-06-30 12:56 Message: Logged In: YES user_id=269193 suse 7.1 or 7.2. kernel 2.19. i cannot apply the patch just now, but i will try tomorrow. tt. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-06-30 10:15 Message: Logged In: YES user_id=33168 What OS are you using? Redhat 6.2, perhaps? Can you test patch 762934? http://python.org/sf/762934 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763153&group_id=5470 From noreply@sourceforge.net Thu Jul 31 17:54:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 09:54:35 -0700 Subject: [Python-bugs-list] [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-30 18:04 Message generated for change (Comment added) made by jbrouwers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- >Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 11:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 05:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply@sourceforge.net Thu Jul 31 18:47:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 10:47:22 -0700 Subject: [Python-bugs-list] [ python-Bugs-780996 ] pynche does not start Message-ID: Bugs item #780996, was opened at 2003-07-31 13: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=780996&group_id=5470 Category: Demos and Tools Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Mihai Ibanescu (misa) Assigned to: Nobody/Anonymous (nobody) Summary: pynche does not start Initial Comment: On a Red Hat 9 box with python 2.3 compiled: -bash-2.05b# python /usr/lib/python2.3/site-packages/pynche/pynche Traceback (most recent call last): File "/usr/lib/python2.3/site-packages/pynche/pynche", line 7, in ? Main.main() File "/usr/lib/python2.3/site-packages/pynche/Main.py", line 220, in main dbfile=dbfile) File "/usr/lib/python2.3/site-packages/pynche/Main.py", line 130, in build dbfile = s.optiondb()['DBFILE'] KeyError: 'DBFILE' By looking at the constructor for Switchboard, if ~/.pynche is missing, then self.__optiondb is the empty hash. Copying a .pynche file from an older python makes pynche happy again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780996&group_id=5470 From noreply@sourceforge.net Thu Jul 31 19:58:02 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 11:58:02 -0700 Subject: [Python-bugs-list] [ python-Bugs-780576 ] test_ioctl fails Message-ID: Bugs item #780576, was opened at 2003-07-30 18:04 Message generated for change (Comment added) made by jbrouwers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Jean M. Brouwers (jbrouwers) Assigned to: Nobody/Anonymous (nobody) Summary: test_ioctl fails Initial Comment: Test case test_ioctl fails when building Python 2.3 on RedHat 8.0, but just one one and not another RedHat 8.0 machine. The initial suspicion was that this failure may be related to this bug report: http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=777867 but that was reported on Debian unstable. It could still be a glibc bug that Python is tickling but the glibc libraries are the same one both machines (at least there is no difference in the version numbers from rpm). rpm -qa | grep -i glibc glibc-devel-2.3.2-4.80.6 glibc-kernheaders-2.4-7.20 glibc-common-2.3.2-4.80.6 glibc-2.3.2-4.80.6 ---------------------------------------------------------------------- >Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 13:58 Message: Logged In: YES user_id=832557 One more piece of data. If I run the test as python regrtest.py -s test_ioctl.py it passsed every single time on the same machine where the failures occurred. ---------------------------------------------------------------------- Comment By: Jean M. Brouwers (jbrouwers) Date: 2003-07-31 11:54 Message: Logged In: YES user_id=832557 Here is more background info. I built Python 2.3 (final) several times and ran "make test" as part of that. The ioctl_test failed two out of three times on one machine and did not fail on another machine. Different machines but the same RH 8 versions. Also, I built several Python beta releases (2.3b1, 2.3b2 and 2.3c2 if I recall correctly) all just once and the test failed there too. I haven't checked further details and don't know whether this is classified as Heisenbug-like behavior or not. But if the test fails, the error message is "test_ioctl failed -- errors occurred in test.test_ioctl.IoctlTests". ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-07-31 05:27 Message: Logged In: YES user_id=6656 Does your failure exhibit the same heisenbug-like qualities as #777867? (e.g. can you reproduce it running tests via regrtest? does it fail in isolation?) Does it fail in the same way, i.e. returning different numbers from the ioctl() call than the getpgrp() call? It doesn't fail on my sorta RH 7.2 box, but I'm thinking of upgrading soon anyway... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780576&group_id=5470 From noreply@sourceforge.net Thu Jul 31 20:33:45 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 12:33:45 -0700 Subject: [Python-bugs-list] [ python-Bugs-776209 ] MacOS9: test_csv fails Message-ID: Bugs item #776209, was opened at 2003-07-23 14:09 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776209&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: test_csv fails Initial Comment: test_cvs fails on MacPython-OS9: test_csv test test_csv crashed -- exceptions.AttributeError: 'module' object has no attribute 'excel' ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 21:33 Message: Logged In: YES user_id=45365 This bug magically disappeared. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776209&group_id=5470 From noreply@sourceforge.net Thu Jul 31 20:36:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 12:36:38 -0700 Subject: [Python-bugs-list] [ python-Bugs-776207 ] MacOS9: test_posixpath fails Message-ID: Bugs item #776207, was opened at 2003-07-23 14:08 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776207&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: test_posixpath fails Initial Comment: test_posixpath fails on MacPython-OS9: test test_posixpath failed -- Traceback (most recent call last): File "Sap:ufs:jack:SWDev:MacPython:Lib:test:test_posixpath.py" , line 329, in test_ismount self.assertIs(posixpath.ismount("/"), True) File "Sap:ufs:jack:SWDev:MacPython:Lib:test:test_posixpath.py" , line 9, in assertIs self.assert_(a is b) File "Sap:ufs:jack:SWDev:MacPython:Lib:unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError I am unsure about the fix, because I don't know what the intention of posixpath.ismount() is on a non-posix system. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 21:36 Message: Logged In: YES user_id=45365 Fixed by skipping the test, which is useless on MacOS9 anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776207&group_id=5470 From noreply@sourceforge.net Thu Jul 31 20:38:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 12:38:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-776205 ] MacOS9: test_strptime fails Message-ID: Bugs item #776205, was opened at 2003-07-23 14:05 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776205&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: test_strptime fails Initial Comment: Test_strptime fails in MacPython-OS9: test test_strptime failed -- Traceback (most recent call last): File "Sap:ufs:jack:SWDev:MacPython:Lib:test:test_strptime.py", line 308, in test_timezone "timezone check failed; '%s' -> %s != %s" % File "Sap:ufs:jack:SWDev:MacPython:Lib:unittest.py", line 268, in failUnless if not expr: raise self.failureException, msg AssertionError: timezone check failed; '' -> 0 != 1 Probably this specific test should be skipped on the mac, which has no useful timezone information. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 21:38 Message: Logged In: YES user_id=45365 Fixed by skipping the timezone test on MacOS9. Timezone support is non-existent anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776205&group_id=5470 From noreply@sourceforge.net Thu Jul 31 20:39:49 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 12:39:49 -0700 Subject: [Python-bugs-list] [ python-Bugs-776203 ] MacOS9: test_urllib fails Message-ID: Bugs item #776203, was opened at 2003-07-23 14:04 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776203&group_id=5470 Category: Macintosh Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacOS9: test_urllib fails Initial Comment: test_urllib fails in MacPython-OS9: File "Sap:ufs:jack:SWDev:MacPython:Lib:test:test_urllib.py", line 109, in test_basic self.assertEqual(result[0], test_support.TESTFN) File "Sap:ufs:jack:SWDev:MacPython:Lib:unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: ':@test' != '@test' probably a call to os.path.normpath() on both sides of the equality test will do the job. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 21:39 Message: Logged In: YES user_id=45365 Fixed by calling os.path.normpath on both side of the test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776203&group_id=5470 From noreply@sourceforge.net Thu Jul 31 20:43:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 12:43:33 -0700 Subject: [Python-bugs-list] [ python-Bugs-781065 ] test_normalization fails Message-ID: Bugs item #781065, was opened at 2003-07-31 14:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781065&group_id=5470 Category: Unicode Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: The LinuxDuck (thelinuxduck) Assigned to: M.-A. Lemburg (lemburg) Summary: test_normalization fails Initial Comment: I d/l the NormalizationTest.txt from unicode.org, as suggested, then run the test as: ----------------------------------- /source/Python-build> ./python ../Python-2.3/Lib/test/regrtest.py -g test_normalization.py test_normalization test test_normalization failed -- 03F9;03F9;03F9;03A3;03A3; 1 test failed: test_normalization ----------------------------------- If I comment out that line in the file, it fails further down: ----------------------------------- test_normalization test test_normalization failed -- 1D2C;1D2C;1D2C;0041;0041; 1 test failed: test_normalization ----------------------------------- GNU C Library stable release version 2.1.3, by Roland McGrath et al. Compiled by GNU CC version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release). Compiled on a Linux 2.2.14 system on 2000-03-20. Available extensions: GNU libio by Per Bothner linuxthreads-0.8 by Xavier Leroy BIND-4.9.7-REL libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Linux www 2.2.16 #22 Fri Jun 16 16:51:24 PDT 2000 i586 unknown unknown GNU/Linux This is a slack 8.1 box, running gcc 3.0.2. Python version 2.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=781065&group_id=5470 From noreply@sourceforge.net Thu Jul 31 20:50:51 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 12:50:51 -0700 Subject: [Python-bugs-list] [ python-Bugs-776202 ] MacOS9: test_uu fails Message-ID: Bugs item #776202, was opened at 2003-07-23 14:02 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 Category: Macintosh Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Jack Jansen (jackjansen) >Assigned to: Walter Dörwald (doerwalter) Summary: MacOS9: test_uu fails Initial Comment: test_uu fails on MacPython-OS9: AssertionError: 'The smooth-scaled python crept over the sleeping dog\r' != 'The smooth-scaled python crept over the sleeping dog\n' Presumably it mixes binary and text I/O. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2003-07-31 21:50 Message: Logged In: YES user_id=45365 I changed the open call to use 'rU' in stead of 'r' (test_uu rev. 1.6.6.1). I get the distinct impression that this isn't the right fix, though, but that the real problem is elsewhere (mixing up text and binary I/O), so I'd like a second opinion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=776202&group_id=5470 From noreply@sourceforge.net Thu Jul 31 23:15:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 31 Jul 2003 15:15:24 -0700 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 13:16 Message generated for change (Comment added) made by jhylton 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: Jeremy Hylton (jhylton) Date: 2003-07-31 22: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 15: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