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

[Guido van Rossum]

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

[Brett]
> 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.

If Python had sets 10 years agon, select would've used sets too. :-)

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

Since Tim thinks it's okay to change (and since I now know what the OP
wanted) you have my blessing to give this a try.

--Guido van Rossum (home page: http://www.python.org/~guido/)