It seems there's a bug in python 2.3

The following script works with python 2.2, not with 2.3

def flatten(L):
	for i in L: 
		if type(i) == list: 
			for j in flatten(i):
				yield j
		else:
			yield i 

def mklist(n):
	if n:
		return [ str(n), mklist(n-1), str(n) ] 
	else:
		return []
 
L = mklist(6) 
print "".join(flatten(L))
 
flatten seems to work but join makes a segmentation fault. 
 
It works fine with print "".join(list(flatten(L)))
or when L = mklist(4)

I'm using Python 2.3 with Linux (Redhat)

Best regards,
Christophe Delord.

Logged In: YES 
user_id=566423

Of course, with a correct indentation, it is:

def flatten(L):
    for i in L:
        if type(i) == list:
            for j in flatten(i):
            yield j
        else:
            yield i

def mklist(n):
    if n:
        return [ str(n), mklist(n-1), str(n) ]
    else:
        return [] 

L = mklist(6)
print "".join(flatten(L))

Logged In: YES 
user_id=31392

When I run the test script, python2.3 says:
654321123456

If I add a future statement to the script and run it with
2.2, I get a core dump.

Logged In: YES 
user_id=31392

The latest CVS on the 2.2 maintenance branch also works
correctly.

I suspect you've hit a bug that is already fixed.  I'm
closing for now, but feel free to re-open if you can provoke
it with a current checkout from CVS.  If so, it would be
helpful if you could provide a stack trace from gdb.

Logged In: YES 
user_id=31392

I was a bit hasty.  It doesn't dump core everytime, but it
does seem to dump core occasionally.  Here's a stack trace
from gdb:
#0  0x806ad98 in _PyTuple_Resize (pv=0xbffff5d8, newsize=12)
    at ../Objects/tupleobject.c:687
#1  0x80b746a in PySequence_Tuple (v=0x4019c72c) at
../Objects/abstract.c:1347
#2  0x80b94bf in PySequence_Fast (v=0x4019c72c, m=0x80d02dc "")
    at ../Objects/abstract.c:1444
#3  0x8065a71 in string_join (self=0x40148098, orig=0x4019c72c)
    at ../Objects/stringobject.c:1212
#4  0x8088166 in fast_cfunction (func=0x4018db0c,
pp_stack=0xbffff724, na=1)
    at ../Python/ceval.c:3108
#5  0x80868c6 in eval_frame (f=0x810afbc) at
../Python/ceval.c:1975
#6  0x80878b2 in PyEval_EvalCodeEx (co=0x4019b360,
globals=0x4015f2d4, 
    locals=0x4015f2d4, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at ../Python/ceval.c:2553
#7  0x80898e0 in PyEval_EvalCode (co=0x4019b360,
globals=0x4015f2d4, 
    locals=0x4015f2d4) at ../Python/ceval.c:482
#8  0x80a42d1 in run_node (n=0x81402f8, filename=0xbffffb23
"/tmp/foo.py", 
    globals=0x4015f2d4, locals=0x4015f2d4, flags=0xbffff928)
    at ../Python/pythonrun.c:1088
#9  0x80a4282 in run_err_node (n=0x81402f8,
filename=0xbffffb23 "/tmp/foo.py", 
    globals=0x4015f2d4, locals=0x4015f2d4, flags=0xbffff928)
    at ../Python/pythonrun.c:1075
#10 0x80a3f01 in PyRun_FileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", start=257,
globals=0x4015f2d4, 
    locals=0x4015f2d4, closeit=1, flags=0xbffff928)
    at ../Python/pythonrun.c:1066
#11 0x80a2af1 in PyRun_SimpleFileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", closeit=1,
flags=0xbffff928)
    at ../Python/pythonrun.c:697
#12 0x80a3a63 in PyRun_AnyFileExFlags (fp=0x8102cb0, 
    filename=0xbffffb23 "/tmp/foo.py", closeit=1,
flags=0xbffff928)
    at ../Python/pythonrun.c:500
#13 0x805374d in Py_Main (argc=2, argv=0xbffff9b4) at
../Modules/main.c:368
#14 0x8052fea in main (argc=2, argv=0xbffff9b4) at
../Modules/python.c:10
#15 0x40077cbe in __libc_start_main () from /lib/libc.so.6

Logged In: YES 
user_id=31392

I think this is fixed in CVS now, but I'm waiting to close
the bug because I don't have a test case for it.  Thanks to
Neal for writing a good checkin message.  (Seriously.)

Logged In: YES 
user_id=566423

I don't get the segmentation fault any more with this last
update.
Your reactivity is so impressive...
Thanks!

Logged In: YES 
user_id=33168

It's the least I could do, since I introduced the bug.
Sorry about that.  The checkin made sense and fixes
Christophe's problem, so should the bug be closed.
Guido checked in a test too.