Martin v. Löwis <mar...@v.loewis.de> added the comment: > Now, I'm much more in favour to remove it from moduleMethods than from > adjusting it to work in py3k.
Would you apply the same reasoning to the other Tkapp methods available on _tkinter? IIRC, these functions were there first; the Tkapp object was added later. The module functions are kept for compatibility (which we were free to break in 3.0). I'm not opposed to removing these module functions now (not even for 3.0.1), but... > 1) To me, it makes much more sense to call a mainloop function from a > Tcl interpreter object than from a module; To me, it makes perfect sense. Windowing events are a global, and not specific to a Tcl interpreter - before receiving it, you cannot know (in general) what interpreter it is for. Indeed, Tcl's Tcl_DoOneEvent doesn't take a Tcl_Interp* parameter. > 2) There is a member named dispatching in TkappObject, so I believe when > this tcl/tk bridge was created -- or at least when this member was added > -- it had the intention to allow multiple mainloops at some time (or is > it really only intended to be used when trying to grab the thread that > created the tcl interpreter ?); This entire machinery got added when Tcl started supporting threads in a way fundamentally different from Python's support for threads. Tcl is inherently single-threaded, no GIL. To support threads, you create a new interpreter for each new thread, and the different interpreters are completely independent from each other. So when a Tkinter application passes a Tcl command from one thread to another, this would crash or otherwise not work. In the old days, Python's threading could be used with Tcl just fine; any thread could make Tk calls (on Unix, at least). When Tcl threading was added, I tried to preserve this mode, by making one thread the Tcl thread. Any other Python thread can't make direct Tcl calls (since those would get to a different interpreter), but instead an RPC system based on Tcl's thread synchronization was added. As this RPC depends on the Tcl mainloop, the "dispatching" member tells the caller if the Tcl thread is up. So, no: the "dispatching" member is there for continued support of a single mainloop, not for multiple mainloops. > 3) It reduces code :) That is a good reason. We would still need a complete patch. _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue3638> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com