[issue2693] IDLE doesn't work with Tk 8.5

Martin v. Löwis report at bugs.python.org
Sun Apr 27 09:09:56 CEST 2008


Martin v. Löwis <martin at v.loewis.de> added the comment:

> I wish I could be as cavalier about Tk 8.5.  The last version of Tk 8.4
> just came out and it really shows its age, especially on Mac OS X, and
> those are ~25% of our application's downloads.

Still, why is that a problem to use it for IDLE?

> Since Python 2.6a2 is
> "not suitable for production use", that leaves us with patching 2.5. 

If you need to patch Python 2.5, just go ahead and do it. You don't need
your patch accepted for that. Python 2.5.3 will likely be released
*after* Python 2.6, at which point the "not suitable for production use"
argument will be invalid.

> Backporting, the _tkinter and Tkinter changes, was not hard, but then we
> get "SystemError: Objects/tupleobject.c:89: bad argument to internal
> function" errors with both the 2.5 and the 2.6a2 idlelibs.  Looking at
> the SVN log, it is not clear which patch to tupleobject.c fixed that
> problem (does anyone know?).

I don't think there was any such change to tupleobject.c. If you got
the internal error after changing something, you probably changed it
incorrectly.

> So fixing WidgetRedirector.py to not screw up the string representation
> of tuples is the easiest solution to get idle to work with Tk 8.5. and
> Python 2.5 (you still would want the Tkinter.py changes for other
> reasons).  A slightly more robust solution would be to use Tcl quoting:
> 
>     r = '{%s}' % '} {'.join(map(str, r))
> 
> But that has not been important in practice.

This is what I'm concerned about. I cannot accept a patch whose
correctness was just established through testing. In fact, I don't
understand what the proposed change actually does: what are the
values of the variables at the point, what is the expected result,
what is the actual result, and how does the patch change that?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2693>
__________________________________


More information about the Python-bugs-list mailing list