[Python-Dev] Re: [Bug #121013] Bug in <stringobject>.join(<unicodestring>)
Tue, 28 Nov 2000 10:35:57 +0000 (GMT)
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)
> 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?