> 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.