On Mon, 27 Nov 2000, Fredrik Lundh wrote: > Michael Hudson wrote: > > > Fredrik's PySequence_Fast_* APIs look interesting, BTW. Should be > > > used more often :-) > > > > Yes. But they're pretty new, aren't they? I find them a bit > > unsatisfactory that it's not possible to hoist the type check out of > > the inner loop. > > if you can figure out a way to do that with C macros, > I'd love to see it... No. You can consider my above comment as a round-about way of saying "I hate C" :-) > on the other hand, PySequence_Fast guarantees that the > returned object is either a list or a tuple, so you can easily > move the test outside the loop yourself: > > if (PyTuple_Check(seq)) > for (...) > item = PyTuple_GET_ITEM(seq, i) > ... > else > for (...) > item = PyList_GET_ITEM(seq, i) > ... But doing that would slightly eliminate the point of the PySequenceFast* API wouldn't it? Rhetorical question; it doesn't really seem to matter. Slightly less rhetorical question: string_join currently just assumes a list of strings. But it is conceivable that one day it might be changed to call __str__ on instances it finds, and then you'd have the issue of __str__ methods changing the length of the list you're iterating over (this might more plausibly apply in other situations where you might want to use PySequence_Fast but I haven't gone looking for them). So would it be feasible to change PySequence_Fast to smash the type of a list it's given with the "immutable_list_type" from listobject.c and then have a PySequence_Fast_End function that would decref the sequence and un-smash the type as appropriate? Cheers, M.
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