I noticed a regression in string.join() behaviour:

Running under Python 2.4 works:
$ python2.4
Python 2.4.4c0 (#2, Apr 22 2006, 22:39:06) 
[GCC 4.0.3 (Debian 4.0.3-1)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> "/".join([u"", u"2"])
u'/2'
>>> 

Running under Python 2.5 SVN build fails:
$ python2.5
Python 2.5a2 (trunk:46757, Jun  8 2006, 22:20:31) 
[GCC 4.1.2 20060604 (prerelease) (Debian 4.1.1-2)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> "/".join([u"", u"2"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: join() is too long for a Python string
>>> 

Logged In: YES 
user_id=55188

That occurrs when join sequence includes a zero-length
unicode object after Tim's r46084. 
I attached a patch but can't sure that it's correct fix yet. :)

Logged In: YES 
user_id=31435

Fudge -- sorry about that!  Your fix is fine.  Adding two
non-negative signed integers of the same width indeed
overflows if and only if the computed result is negative.  I
was hallucinating when I imagined that a 0 result also
indicated overflow (something related to that is a correct
fast test when dealing with unsigned integers, but we're not
here).

Logged In: YES 
user_id=849994

I applied the fix in rev. 46812. I also added the new test
to the 2.4 branch in rev. 46813.