[Python-Dev] Changing select.select to accept iterables (original) (raw)

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 fdset 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 PyListGetItem; 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 > PySequenceFast(), then > s/PyListGetItem/PySequenceFastGETITEM/. > 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