[Python-Dev] Changing select.select to accept iterables

[Brett C.]

Tim Peters wrote:

> [Brett, about <http://www.python.org/sf/798046>]
> 
> [Guido]
> 
>>I seem to recall that that code has a long history of being hairy
>>and full of platform-specific issues, and I'd rather not see it
>>disturbed by an unspecific desire for more generalization.  Why can't
>>the OP produce the input in the form of lists?
> 
> 
> They could, but they specifically already have Sets of socket objects.
> That's what C would have used too for select(), if it had sets, so it's a
> natural desire.  The SF report notes that when read and write lists change
> frequently, it's a lot more efficient to add/remove sockets via O(1) Set
> operations.  Under the covers, select() setup takes O(N) time even if the
> inputs are native list.
> 

Tim is right about there not being a restriction of not being able to 
create a list but wanting a better data structure for the job.

And again I suspect Time is right about the socket API designers wanting 
sets if they had it in ANSI C; probably why they call it an fd_set for 
storing what file descriptors to work on.

As for the code being hairy, yes, it does have its share of #ifdefs. 
But the list checks and code directly handling the lists are outside of 
any #ifdefs.  The list codes is literally just the list checks and a 
'for' loop pulling out each item in the list using PyList_GetItem; after 
that everything operates on what was pulled out of the list.  But I 
understand the reluctance of messing with code that has a reputation and 
his a pain to test for something that is just a perk.

> Functions that expect input lists of reasonably small size (thousands, sure;
> millions, probably not) can usually be generalized to iterables easily, with
> little chance of disruption, by replacing initial "is it a list?" check with
> a call to PySequence_Fast(), then
> s/PyList_GetItem/PySequence_Fast_GET_ITEM/.
> 

Is this the preferred way of dealing with places where a small sequence 
and such will be instead of bothering with iterators, or is this a 
hold-over from pre-iterators and thus iterators are the proper way to go 
in new code and in old code where reasonable and relatively painless?

Since Guido has previously expressed reluctance in having me touch this 
code I won't unless he tells me otherwise.

-Brett