On 24 May, 2012, at 14:03, Antoine Pitrou wrote:
On Thu, 24 May 2012 13:50:27 +0200 Giampaolo Rodolà
wrote: 2012/5/24 Ronald Oussoren
: On 24 May, 2012, at 3:32, Giampaolo Rodolà wrote:
>
The handler is supposed to provide 3 methods: - handle_read_event - handle_write_event - handle_error_event
Users willing to support multiple event loops such as wx, gtk etc can do:
> while 1: ... poller.poll(timeout=0.1, blocking=False) ... otherpoller.poll()
Basically, this would be the whole API.
Isn't this a limited version of asyncore? (poller.poll == asyncore.loop, the handler is a subset of asyncore.dispatcher).
Ronald
poller.poll serves the same purpose of asyncore.loop, yes, but this is supposed to be independent from asyncore.
I agree with Ronald that it looks like a less-braindead version of asyncore. I don't think the select module is the right place.
What worries me most is that it might only look like a beter version of asyncore. I'd much rather see something based on the event-handling core of Twisted because that code base is used in production and is hence more likely to be correct w.r.t. odd real-world conditions. IIRC doing this was discussed at the language summit in 2011, but as Nick mentions that doesn't seem to be the focus of PEP 3153. I am by the way not using Twisted myself, I'm at this time still using homebrew select loops and asyncore.
Also, I don't know why you would specify poller.READ or poller.WRITE explicitly. Usually you are interested in all events, no?
You're not always interested in write events, those are only interesting when you have data that must be written to a socket. Ronald