On Jul 1, 2005, at 3:54 PM, David wrote:
I am not yet a twisted programmer, so my contribution to this thread has more to do with English interpretation than with twisted.
A principle problem with event mainloops is that each toolkit wants to provide one, and the program can only have one running at a time (barring multithreading fanciness). When I read the original post referring to the discussion with GvR, I thought, cool, a resolution to the different-mainloops-for-different-tool kits problem: a mainloop that can integrate various tool kits.
It seems that all other respondents have interpreted it as a call to include twisted, or parts of it _as is_, in the stdlib. I did not see in the original post a call for twisted _networking_ inclusion at all.
When I read about twisted on other lists (the pygame list comes to mind), the examples almost always use the poll() reactor method, because it allows you to use twisted from your own mainloop; you can then integrate other tool kits into that home-spun mainloop by whatever provisions they allow for doing so.
We shouldn't have to be that creative. There should be one std dist mainloop that can accommodate, via callbacks perhaps, whatever (multiple) services need a mainloop. So a tkinter-twisted mainloop and a gtk-twisted mainloop would not be needed as separate components.
I am too naive to write such a library, nor even to write a PEP, so I won't be running with this, but is there something impossible about my interpretation?
That's a nice idea, but it can't possibly work. If you want a general way to interoperate with different toolkits, you basically have to use multithreaded fanciness, because not many of them have timers or socket notifiers built in worth their salt. Starting a single thread to sit around and wait for select() or equivalent is pretty sane, and makes the interface a lot more flexible and generic since you only need one facility in the toolkit -- namely a thread- safe way to call back into the main thread. Fortunately, there is one in Twisted 2.1, threadedselectreactor, which DOES integrate with various runloops (pygame and wxPython included) without polling. However, it's not the end of the road. threadedselectreactor should be refactored into a general interface (interleave) such that other backends (epoll, kqueue, windows junk, etc.) can be used rather than select. -bob