On 03.05.2018 20:11, Ryan Gonzalez wrote:
On May 3, 2018 11:56:24 AM MRAB <pyt...@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@python.org <mailto:python-dev@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.mo...@gmail.com <mailto:p.f.mo...@gmail.com>> wrote:

            On 2 May 2018 at 22:37, Antoine Pitrou <solip...@pitrou.net
            <mailto:solip...@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@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@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

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to