> Martin v. Löwis <martin@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?
>

As I see all those functions that are calling into Tcl should be moved
from the module functions. Some parts of the code inside these
functions are conflicting with each other, while one will try to allow
multiple threads, the other part will just disallow it. And since to
follow the Tcl appartment model we need to access some of the members
in TkappObject it just makes me want to remove those functions even
more.

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

That is way to see it. But what I was taking into account was
something like the proper update of the dispatching member for
different interpreters, this would mean dispatching could be used to
stop a running mainloop by setting it to 0.

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

That is exactly one of the reasons to move mainloop and others from
the moduleMethods. It is hard for me to accept the two distinct
behaviours present in _tkinter, which are based from where you call
the function.

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

But I don't see a RPC being used there, I just see some polling.

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