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.moore@gmail.com <mailto:p.f.moore@gmail.com>> wrote:
On 2 May 2018 at 22:37, Antoine Pitrou <solipsis@pitrou.net <mailto:solipsis@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 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 unexpectedly. [snip]