[Tim] >> 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/. [Brett C.] > 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? It's rare that you *know* an input will be at worst of reasonably small size, and that's why PySequence_Fast() isn't used more often (plus, I suppose, that it's relatively little known). It's perfect for select() inputs, which are not only certain to be reasonably small in working programs (no working program can use millions of sockets simultaneously), but also can't get any benefit from the "early out" possibilities afforded by using the iterator protocol instead. > Since Guido has previously expressed reluctance in having me touch > this code I won't unless he tells me otherwise. The change you'd like to make is very low-risk if you use the PySequence_Fast() approach, mainly simple editor substitutions, and Guido will like the idea of passing Sets to select() once he tries it <wink>.
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