[toast0]

Yes, I know processes are different than threads, but the basic idea is similar -- a process is an execution context with its own stack and program counter and etc; so is a thread, but the etc differs. That python knows how to run in threads means it's at least got some of the basics that might enable it to run in multiple contexts, was my only point.

I agree that it would be a lot different architecture than a normal python application; but where there could be value, is if you wanted to write a distributed thing in python with all the nice properties you get from an erlang system, your choices now are either drop python (my preference!); write dist/otp yourself, but in python (hard, because how do you bolt on monitors, etc); write just enough erlang to coordinate python running as port commands (probably doable, but could be fragile).

I personally would love to run a little bit of perl on the beam, but i know it's crazy, so I don't mention it very often ;)

[saurik]

The "etc" is absolutely critical as it is shared memory: BEAM works the way it does specifically because it does not want to model shared memory, which means any implementation of threads over it will be an incredibly painful and certainly ludicrously slow simulation, and there is nothing in Python that really maps to the primitive BEAM offers.