> BaseSelector.register(fd) raises a KeyError if fd is already registered, which means that any selector must know the list of all registered FDs. For EpollSelector, the list may be inconsistent *if* the epoll is object is modified externally, but it's really a corner case.

Yes, and there's nothing we can do about it :-(

> What do you think of having some mapping methods?
>
> - iter(selector), selector.keys(): : iter(self._fd_to_key), iterator on file descriptor numbers (int)
> - selector.values(): self._fd_to_key.values(), iterate on SelectorKey objects
> - selector.items(): self._fd_to_key.items(), iterator on (fd, SelectorKey) tuples

I don't know, it makes me uncomfortable treating a selector like
a plain container.

> "SelectorKey" name is confusing, it's not really a key as a dictionary dict. SelectorKey.fd *is* the key, Selector.event is not.
>
> "SelectorFile" or "SelectorItem" would be more explicit, no?

It's more key as "indexing key", or token: it's the interface between the selector and the external world.
The FD "is" indeed the key internally, but that's an implementation detail.

I'd really like to have Guido's feeling regarding the above questions.

> By the way, is SelectorKey.fileobj always defined? If not, the documentation is wrong: the attribut should be documented as "Optional", as .data.

Yes, it's always defined: it's the object passed to register().