[Python-checkins] python/dist/src/Objects unicodeobject.c, 2.219, 2.220

[M.-A. Lemburg]

tim_one at users.sourceforge.net wrote:
> Update of /cvsroot/python/python/dist/src/Objects
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15103/Objects
> 
> Modified Files:
> 	unicodeobject.c 
> Log Message:
> PyUnicode_Join():  Two primary aims:
> 
> 1. u1.join([u2]) is u2
> 2. Be more careful about C-level int overflow.
> 
> Since PySequence_Fast() isn't needed to achieve #1, it's not used -- but
> the code could sure be simpler if it were.

Hmm, you've now made PyUnicode_Join() to work with iterators
whereas PyString_Join() only works for sequences.

What are the performance implications of this for PyUnicode_Join() ?

Since the string and Unicode implementations have to be in sync,
we'd also need to convert PyString_Join() to work on iterators.

Which brings up the second question:
What are the performance implications of this for PyString_Join() ?

The join operation is a widely used method, so both implementations
need to be as fast as possible. It may be worthwhile making the
PySequence_Fast() approach a special case in both routines and
using the iterator approach as fallback if no sequence is found.

Note that PyString_Join() with iterator support will also
have to be careful about not trying to iterate twice, so
it will have to use a similiar logic to the one applied
in PyString_Format() where the work already done up to the
point where it finds a Unicode string is reused when calling
PyUnicode_Format().

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 27 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::