On 2013-02-05, Dennis Lee Bieber wrote:
> I'll echo the "Ugh" about the use of global AND ADD a dislike of the
> busy loop that only exits if some other return sets a value. If the busy
> loop were performing some action that changed the test state within the
> loop itself, okay...
TBH, I was originally going to use
input('press RETURN to continue')
but I thought it would be nicer to click on the plot window.
> -=-=-=-
> import threading
>
> evtFlag = threading.Event()
This is a global variable, but here we're calling a method on it
rather than changing its value (boolean in my original case). Why is
that better in principle?
> def clicked(x, y):
> print("clicked at %f %f" % (x, y))
> evtFlag.set()
> #don't need "global" as not binding to the name evtFlag
> #don't need "return" as falling off the end of the function
> # implements return
Does it do any harm to put an empty "return" at the end of a method?
(It looks tidier to me with the return.)
> def wait_for_clicks(s):
> evtFlag.clear()
> s.listen()
> evtFlag.wait()
> #don't need "global" or "return"
> #don't need busy loop; .wait() blocks until some other thread
> # (GUI callback) sets the Event
I tried these and got even worse results --- even Ctrl-C in the xterm
I was running the program from wouldn't kill it; I had to use Ctrl-Z
and kill %1.
--
It would be unfair to detect an element of logic in the siting of the
Pentagon alongside the National Cemetery, but the subject seems at
least worthy of investigation. --- C Northcote Parkinson
--
http://mail.python.org/mailman/listinfo/python-list
