Here's a Python 2 segfault I ran into recently.

    import sys, threading, time
    
    t = threading.Thread(target=sys.stdin.read, args=(1,))
    t.start()
    time.sleep(1)
    sys.stdin.close()

Run it then after a few seconds press enter. It doesn't segfault in Python 3, but it still doesn't behave how I'd like, because I would like the close() to unblock the read(), but it doesn't unblock the read(), the read() still hangs until it gets some input.

The whole threading library in Python is a mess. Python was designed around single threaded programs with shared-nothing state and the cracks show as you move beyond that. The whole idea of replacing the GIL with... multiple same-process distinct-state Python interpreters with cheap-ish message passing sort of highlights how ugly it gets.

Back around python 1.5, there was almost a fork of python where every object had locks, there were memory arenas, and multiprocessing was almost thoughtlessly easy. That and stackless would've been great.

It was also terribly slow.

IronPython did that too, on .Net. It ran around one quarter the speed of CPython.

More recently than that, too, unless I'm misremembering. As sibling commenter points out, such a model is horrifically slow. Lock-for-every-object is too granular to perform well.

At least that one is an abort…