[Python-Dev] Drop/deprecate Tkinter?
vano at mail.mipt.ru
Thu May 3 14:24:02 EDT 2018
On 03.05.2018 20:11, Ryan Gonzalez wrote:
> On May 3, 2018 11:56:24 AM MRAB <python at mrabarnett.plus.com> wrote:
>> On 2018-05-03 13:24, Steve Holden wrote:
>>> On Thu, May 3, 2018 at 12:12 AM, Ivan Pozdeev via Python-Dev
>>> <python-dev at python.org <mailto:python-dev at python.org>> wrote:
>>> On 03.05.2018 1:01, Antoine Pitrou wrote:
>>> On Wed, 2 May 2018 22:54:04 +0100
>>> Paul Moore <p.f.moore at gmail.com
>>> <mailto:p.f.moore at gmail.com>> wrote:
>>> On 2 May 2018 at 22:37, Antoine Pitrou <solipsis at pitrou.net
>>> <mailto:solipsis at pitrou.net>> wrote:
>>> To elaborate a bit: the OP, while angry, produced
>>> both a
>>> analysis *and* a PR. It's normal to be angry when an
>>> feature doesn't work and it makes you lose hours of
>>> (or, even,
>>> forces you to a wholesale redesign). Producing a
>>> detailed analysis and a
>>> PR is more than most people will ever do.
>>> His *other* email seems reasonable, and warrants a
>>> yes. But
>>> are we to take the suggestion made here (to drop tkinter)
>>> based on the fact that there's a (rare - at least it
>>> that the
>>> many IDLE users haven't hit it yet) race condition that
>>> causes a crash
>>> in Python 2.7? (It appears that the problem doesn't happen
>>> in the
>>> python.org <http://python.org> 3.x builds, if I understand
>>> the description of the issue).
>>> In 3.x, Tkinter+threads is broken too, albeit in a different way --
>>> see https://bugs.python.org/issue33412
>>> <https://bugs.python.org/issue33412> (this should've been the 2nd
>>> link in the initial message, sorry for the mix-up).
>>> The observation in that issue that tkinter and threads should be
>>> handled in specific ways is certainly a given for old hands, who have
>>> long put the GUI code in one thread with one or more concurrent worker
>>> threads typically communicating through queues. But I haven't built
>>> anything like that recently, so I couldn't say how helpful the current
>>> documenation might be.
>> Interacting with the GUI only in the main thread is something that I've
>> had to do in other languages (it is/was the recommended practice), so I
>> naturally do the same with Python and tkinter. It's also easier to
>> reason about because you don't get elements of the GUI changing
> To add to this, most GUI frameworks disallow modifications outside the
> main thread altogether. IIRC both GTK+ and Qt require this, or else
> it's undefined altogether.
You still need some facility (*cough*SendMessage*cough*) to send update
commands to the GUI (the model->view link in MVC, presenter->view in MVP).
Who and how specifically carries out these commands is unimportant, an
Every GUI has an event/message queue exactly for that, that other
threads can sent work requests into:
, the aforementioned WinAPI's SendMessage() and PostMessage() just to
name a few.
Tcl/Tk, being arguably the oldest usable GUI toolkit in existence, has
an event queue likewise but doesn't provide a complete event loop
implementation, only the building blocks for it. Tkinter fills that gap
with its `tk.mainloop()`.
It fails to provide a working means to send work into it though. Having
to use a second, duplicating event queue and poll it (=busy loop)
instead is an obvious crutch.
>> Python-Dev mailing list
>> Python-Dev at python.org
> Ryan (ライアン)
> Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
> Python-Dev mailing list
> Python-Dev at python.org
More information about the Python-Dev