| msg18179 - (view) |
Author: Paul Perkins (ranger1) |
Date: 2003-09-17 15:18 |
| Bug: tkMessageBox.askyesno can return wrong result. Bug in python 2.3, built from source on SuSE 8.2 Linux box with gcc (GCC) 3.3 20030226 (prerelease) (SuSE Linux). To demonstate bug: 1. Run attached program in a shell window under X. 2. Click "askyesno" button in main window. 3. Click "Yes" button in the new window. 4. Observe printed result "True" in shell window. 5. Click "openfiledialog" button in main window. 6. Cancel the file dialog (or select a file, it doesn't matter). 7. Click "askyesno" button in main window. 8. Click "Yes" button in the new window. 9. Observe printed result "False" in shell window. Using the debugger in idle, one can see that the difference is that Tk returns "yes" to Python in step 3, but True in step 8. In python 2.2 (as built by SuSE for 8.2), the printed result is always "1" in steps 3 and 8. |
|
|
| msg18180 - (view) |
Author: SomeOne (regenkind) |
Date: 2003-10-18 15:49 |
| Logged In: YES user_id=1592 I have downloaded the file and executed it on windows 2000, py2.3.2 and could not observe this behaviour. I get both times true. |
|
|
| msg18181 - (view) |
Author: Michael Bartl (midramas) |
Date: 2003-10-19 22:13 |
| Logged In: YES user_id=31511 Tested on Linux with python HEAD from cvs. Bug could be reproduced and is still present. |
|
|
| msg18182 - (view) |
Author: Jiba (jiba) |
Date: 2004-08-29 10:30 |
| Logged In: YES user_id=591223 I have this bug too, with Python 2.3.4 on Linux Mandrake. |
|
|
| msg18183 - (view) |
Author: Jiba (jiba) |
Date: 2004-08-29 11:17 |
| Logged In: YES user_id=591223 I've just submitted patch 1018509 for this bug. It is a quick fix ; i believe the real bug is in Tcl/Tk. |
|
|
| msg18184 - (view) |
Author: Peter Kleiweg (peterkleiweg) |
Date: 2004-09-08 12:37 |
| Logged In: YES user_id=1118097 It doesn't look like a bug in tcl/tk because the return type is also wrong. The function tkMessageBox._show() should return a string 'yes', but returns a bool 'True', not just a string 'True'. (But always a string 'no', never a bool 'False'.) Since tcl/tk doesn't have bools, only strings, this error most originate within Python. I encountered the same problem om one platform, but not on several others. Details below. Neither the version of tcl/tk nor that of Python seems conclusive. Perhaps this bug depends on the compiler version used? It also happens only after calling tkFileDialog.askopenfilename(), never before. Problem in this version: Python 2.3+ (#1, Jan 7 2004, 09:17:35) [GCC 3.3.1 (SuSE Linux)] on linux2 Libs used by Python binary: libpython2.3.so.1.0 => /usr/lib/libpython2.3.so.1.0 (0x40046000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40133000) libdl.so.2 => /lib/libdl.so.2 (0x40184000) libutil.so.1 => /lib/libutil.so.1 (0x40187000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x4018a000) libm.so.6 => /lib/i686/libm.so.6 (0x4024b000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4026e000) libc.so.6 => /lib/i686/libc.so.6 (0x40276000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.4 (also tested with Python 2.3.4 on this machine, same error) No problem (this is on another machine): Python 2.3.4 (#1, Aug 6 2004, 18:12:39) [GCC 2.95.3 20010315 (SuSE)] on linux2 Libs used by Python binary: libpthread.so.0 => /lib/libpthread.so.0 (0x4002c000) libdl.so.2 => /lib/libdl.so.2 (0x40042000) libutil.so.1 => /lib/libutil.so.1 (0x40046000) libm.so.6 => /lib/libm.so.6 (0x40049000) libc.so.6 => /lib/libc.so.6 (0x4006d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Tcl/Tk 8.3 No problem: Windows98 PythonWin 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32. Tcl/Tk 8.4 No problem: Windows98 Python 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] on win32 Tcl/Tk 8.4 |
|
|
| msg18185 - (view) |
Author: Peter Kleiweg (peterkleiweg) |
Date: 2004-09-08 21:39 |
| Logged In: YES user_id=1118097 The problem disappears if you start your program with these two lines (before creating any widgets): import Tkinter Tkinter.wantobjects = 0 |
|
|
| msg18186 - (view) |
Author: Jiba (jiba) |
Date: 2004-09-09 08:43 |
| Logged In: YES user_id=591223 I confirm the "wantobjects" hack works for me. |
|
|
| msg18187 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2004-09-18 16:06 |
| Logged In: YES user_id=21627 This is now fixed in tkMessageBox.py 1.3, 1.2.10.1 NEWS 1.831.4.151 I'd be still curious at what point Tcl converts the string "yes" into a boolean, and why this happens only on some installations. |
|
|
| msg18188 - (view) |
Author: Peter Kleiweg (peterkleiweg) |
Date: 2004-09-21 23:20 |
| Logged In: YES user_id=1118097 I can only find a change in file lib-tk/tkMessageBox.py. Is this a true fix for expected behaviour of Tk? Or is this just a workaround for something murky deeper in Tk that may or may not be a bug? Is there perhaps a bug in the new behaviour of Tkinter that gets activated through the variable 'Tkinter.wantobjects'? |
|
|
| msg18189 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2004-09-22 06:29 |
| Logged In: YES user_id=21627 I don't see a bug in the integration of Tcl objects into Python. Do you? |
|
|
| msg18190 - (view) |
Author: Jiba (jiba) |
Date: 2004-09-22 10:52 |
| Logged In: YES user_id=591223 peterkleiweg : it's a workaround. It's better than nothing and it fixes the bug, but i fear the real bug is still somewhere hidden in _tkinter.c... i've searched for it, but i didn't find it though :-( |
|
|
| msg18191 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2004-09-22 18:28 |
| Logged In: YES user_id=21627 I'm certain the bug is not in _tkinter. If _tkinter says it is a boolean (True or False), then only because Tcl told it is a boolean. Tcl tells so if somebody inside Tcl tried to convert the string to a boolean, and, unfortunately, "yes", "true", and a number of other string values all convert to logical true, and "no", "false", and some others convert to logical false. The remaining question is why that conversion is invoked for the dialogs (when the strings clearly are not meant as boolean values); this can be best found out by setting a breakpoint on Tcl_GetBoolean, SetBooleanFromAny, and possibly the 'y' case of GetLexeme. |
|
|