The select module only allows lists, not any 
iterable.  While this may slightly increase efficiency 
for the select.select() function itself, for many 
applications passing select.select a sets.Set would 
probably be much more efficient (i.e., when things 
are being added/removed from the readable or 
writable lists quite often, the O(n) removal of lists 
would certainly be worse than the O(1) removal of 
sets.) 

Logged In: YES 
user_id=4771

Using select.poll() instead of select.select() might be a
good alternative, at least on platforms that support it, if
the sets are getting large enough for you to want to avoid
having to build lists explicitely as in :

    select.select(list(a), list(b), list(c))

Logged In: YES 
user_id=357491

There seems to be two things that are preventing the use of an 
object that supports the iterator protocol instead of a list.  One is 
the explicit check that the arguments are lists; PyList_Check is run 
on the passed-in lists for a basic sanity check.  Then there is a call 
to a function called list2set that takes in a Python list and then 
sets the passed-in fd_set properly.  In that function there is 
nothing that screams "we should only use lists" beyond it allows 
assuming a list and thus doesn't have any hoops to jump through.

But the iterator protocol was set up to minimize hoop jumping.  
There seems to be little stopping a move over to using the iterator 
protocol beyond a minimial amount of recoding to rip out the list 
check to replace it with PyIter_Check and instead of using a 'for' 
loop through a list you just use a 'while' calling PyIter_Next .

But since this seems to have gone so long without being changed I 
would feel better about having someone tell me it is okay to 
change.  I will email python-dev and ask.

Logged In: YES 
user_id=357491

Rev. 2.74 of Modules/selectmodule.c has select.select() accept a 
sequence (as defined by PySequence_Fast()) for its first three 
arguments; this includes sets.

Changed to an RFE since it wasn't really a bug and closed.