[Python-Dev] Re: [Bug #121013] Bug in <stringobject>.join(<unicodestring>)

[Michael Hudson]

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.