This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients gvanrossum, neologix, pitrou, vstinner
Date 2013-10-06.14:28:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAMpsgwZNCEK9a0T+Ex1tRPtRL6ReUUoa0tk+hxMGrAGuoBMfzw@mail.gmail.com>
In-reply-to <1381052245.58.0.899226793327.issue19172@psf.upfronthosting.co.za>
Content
2013/10/6 Charles-François Natali <report@bugs.python.org>:
>> 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 :-(

Oh, I just mentioned to corner case to say that it would nice to
expose the length of a selector.

>> 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.

I don't know if there is a real use case.

>> 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().

Oh, selector.register(0).fileobj gives me 0... I didn't know that 0 is
a file object :-) I would expect .fileobj=None and .fd=0.
History
Date User Action Args
2013-10-06 14:28:09vstinnersetrecipients: + vstinner, gvanrossum, pitrou, neologix
2013-10-06 14:28:09vstinnerlinkissue19172 messages
2013-10-06 14:28:08vstinnercreate