Sorry, replying to some direct questions in the bug:

> I also made the following changes:
> - BaseSelector is an abstract base class (so one could imagine user code
> implementing its own selector on top of it)

Fine (though I had to work around this for some tulip tests).

> - SelectorKey is a named tuple: I think that's better than a class,
> because SelectorKeys can be returned to the user (register(), get_info(),
> etc), and we don't want him to mess with them. Also, we get a nice repr()
> for free

Fine.

> - since SelectorKey is immutable, I added a get_keys() method, which
> returns all the keys registered. Since it's a dict values, the user can't
> mess with it

Fine. (I missed this in the code review.)

> This get_keys() method superseedes the registered_count() method, which
> can be simply replaced with len(selector.get_keys()). We could probably
> remove it? It also sort of superseedes the get_info() method: I don't
> remember, why was it needed?

registered_count() is only used internally so you can kill it.

get_info() is important for Tulip, please keep it.

> Would it be possible to get it into 3.4?

I think so, if Antoine agrees. The next alpha would be at your service.