Author neologix
Recipients neologix, pitrou, vstinner
Date 2013-10-05.22:10:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM0njNfm_kXxT+CfrfH-Z8WuqXTTh=QADEDRRUQZ=xjXdw@mail.gmail.com>
In-reply-to <CAMpsgwb6VhsQG6rvxuux+KV82C=8mmj_Qgpjrvf3pg2gTk+DGA@mail.gmail.com>
Content
> If you want to unregister while iterating on .keys(), just copy .keys(), as
> I do when removing items from a list or a dict while iterating on it.

Of course, but as noted by Antoine, it makes the return type dependent of an
implementation detail (I don't think there's any other place in the stdlib
where a dict view is returned).

> Using .keys() to test if the selector is empty is surprising. To test if a
> str, list, tuple, dict, set, ..., is empty: if container: <not empty> is
> enough.
>
> Or sometimes I write if len(container): ...
>
> Selector has no length?

No. For example, select.epoll objects don't have a length either.
I'm not sure whether selectors have a natural length: if we added a __len__,
we should also add __iter__ and IMO a selector isn't a container.

Returning all the keys is a generic method that can be useful besides checking
that the selector has registered keys.

> So perhaps two methods are needed:
> - a keys() method returning an iterator
> - a has_keys() method returning a boolean

Sounds a bit overkill, no?
keys() is definitely usful, and I'm not sure that it'll actually be a
performance
bottleneck in practice.
History
Date User Action Args
2013-10-05 22:10:51neologixsetrecipients: + neologix, pitrou, vstinner
2013-10-05 22:10:50neologixlinkissue19172 messages
2013-10-05 22:10:50neologixcreate