> - How shall we go forward?  I've made a variety of small changes to the
> Tulip version (selector.py) now.  Can you work those into a fresh unified
> patch for CPython 3.4?

Yes, but I think we could wait a little, to make sure the API is good
enough to fulfill all tulip's need?
There are a couple things I'm not completely happy with:
- if we add a CONNECT event, then I think SELECT_IN/SELECT_OUT aren't
good names anymore: I think that EVENT_READ/EVENT_WRITE/EVENT_CONNECT
would be more consistent (since it embeds the operation that should
now succeed on the socket). Maybe even shorter names like EVT_READ?
- right now, selectors don't handle EINTR, which means that upon
reception of a signal, Selector.select() can fail with EINTR (the
original tulip implementation also had this problem). I've been more
or less midly advocating to change all Python syscalls wrappers to
handle EINTR because it's really just a nuisance, but I think
Selector.select() should definitely handle EINTR and retry the
syscalls (with an updated timeout).
Note: the test testAddSignalHandler() added recently doesn't
demonstrate this problem because os.kill(os.getpid(), signal.SIGINT)
because the signal is delivered synchronously (when kill() syscall
returns to user-space), before select()/poll()/epoll() gets called.

> - I'll change _Key to Key in the Tulip copy (though I wonder if maybe it
> should be a longer name -- 'Key' is rather generic).

SelectorKey, or something along those lines?

> - Are you going to implement the SELECT_CONNECT flag?

Unfortunately, I don't know anything about Windows, so I won't be able to.
But I guess that porting Pollster.WSAPollster to selectors shouldn't
be too hard.

> - Have you submitted a PSF contributor form yet?  (Probably yes, years ago,
> just making sure. :-)

Actually, I already have commit rights ;-)