[Jtsummers]

Re inconclusive:

Erlang's language is concise, well-designed, and oriented around the concurrency model. Try tacking it onto C and it won't work well [0]. Take that concurrency model and put it into Python or Lisp or Smalltalk, and it could work fine. Those are expressive languages that are sufficiently malleable to bring in foreign concepts in a native looking fashion.

[0] It won't look as clean. It'll work, but it won't be clean. We actually use a very similar model in a project at work. But there's so much bookkeeping because it's C that Erlang hides from you. Other expressive languages would be able to absorb that bookkeeping and hide it from you as well, but C isn't expressive. It's precise. It does what you tell it to do. But it's not able to hide things cleanly behind abstractions that the language itself isn't already built to handle.

[saurik]

I agree with Lisp (and it has even been done by key Erlang people), I am willing to believe SmallTalk (though it would be tempting to put the process boundary around every instance), but Python? Have you watched the early talks about why Erlang is designed the way that it is? Python is way way too imperitive in nature, having a syntax that makes functional subsets extremely limited and awkward.

[Jtsummers]

In my limited experience I feel my intuition is correct that you could make something that looks and mostly acts like erlang's concurrency stuffs in python. But it's not my main language by a long shot so I could well be wrong.