This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author PythonInTheGrass
Recipients PythonInTheGrass
Date 2011-01-31.15:40:31
SpamBayes Score 2.64434e-10
Marked as misclassified No
Message-id <>
The more I look at GUI support in Python, the more I realize that the lack of basic thread safety in GUI support is simply a bug. I know Java's Swing has the same thread limitation, but that doesn't make it right. Xlib is thread safe. The Windows SDK is thread safe. Python is supposed to be the language that's easy to use, and there is nothing easy about teaching new programmers that they have to mess with queues and timers just to get a basic set of displays running, just because when threads are in use.

I'm in the position of teaching folk with little-to-no programming experience, how to script simple applications in Python. The modules they have to use are inherently threaded, and delivery hunks of data from multiple sources to them. The most natural instinct is to put up some graphs and other widgits to display the data, and all of it is completely trivial right up until I have to explain that drawing a line isn't canvas.line(from, to), but becomes an exercise in Queue.Queue and theRoot.after(n, myself), before you even get to learn about widgits. Threading is supposed to simplify problems, not add to them. Having to hack around with special timers and polling, just to get some simple graphs up, is plain unpythonic.

Please consider this a bug, a glaring misfeature, in a language that is otherwise a very reasonable choice to get technical but non-programmerish people into toolmaking self-sufficiency.
Date User Action Args
2011-01-31 15:40:32PythonInTheGrasssetrecipients: + PythonInTheGrass
2011-01-31 15:40:32PythonInTheGrasssetmessageid: <>
2011-01-31 15:40:32PythonInTheGrasslinkissue11077 messages
2011-01-31 15:40:31PythonInTheGrasscreate