[Python-Dev] Changing select.select to accept iterables
Guido van Rossum
guido at python.org
Sat Sep 6 21:49:16 EDT 2003
> > [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/)
More information about the Python-Dev
mailing list