> Bug #798046 basically requests that select.select accept iterables > instead of only lists. I took a look at the code and beyond > PyList_Check()s and a function called list2set that expects a Python > list to be passed that can easily be changed to take in an iterable I > see no need to keep the restriction. > > But this module is old and I suspect it is used a good amount (the thing > started at ver. 2.1 by Guido back in 1992). Since it seems to have gone > this long without being changed to use the iterator protocol I wanted to > double-check that changing it would be okay. The only reason I can > think of why it wouldn't be is performance, as suggested by the OP of > the bug report. > > And in general, when something like this that smacks of, "there is no > obvious reason to keep it this way", even though it could have been > changed a while ago and the CVS log seems to not mention anything > against the change, should the change just be made? Or should I just > ask like this to be safe? I have a sneaking suspicion the answer is, > "just change it, Brett! Use your judgment! Don't be so timid!" But > then at least this way I minimize getting chewed out for breaking code. > > Then again, being yelled at makes you think like a Dutchman faster than > anything I know of. =) 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? --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4