[Python-Dev] Drop/deprecate Tkinter?

Ivan Pozdeev 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
>>>                 detailed
>>>                 analysis *and* a PR.  It's normal to be angry when an
>>>                 advertised
>>>                 feature doesn't work and it makes you lose hours of 
>>> work
>>>                 (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 
>>> response,
>>>             yes. But
>>>             are we to take the suggestion made here (to drop tkinter)
>>>             seriously,
>>>             based on the fact that there's a (rare - at least it 
>>> appears
>>>             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 t​hat 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
>> unexpectedly.
>
> 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 
implementation detail.

Every GUI has an event/message queue exactly for that, that other 
threads can sent work requests into:
https://doc.qt.io/qt-5.10/qcoreapplication.html#postEvent , 
https://developer.gnome.org/gdk3/stable/gdk3-Threads.html#gdk3-Threads.description 
, 
https://en.wikipedia.org/wiki/Event_dispatching_thread#Submitting_user_code_to_the_EDT 
, 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.
>>
>> [snip]
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: 
>> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com
>
>
> -- 
> Ryan (ライアン)
> Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
> https://refi64.com/
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru

-- 
Regards,
Ivan



More information about the Python-Dev mailing list