Monitor/Link and Cast/Call are all built ontop of the regular message passing functionality of the language. The point I 'whitehat fibbed' to make stands though, python might be feasable as a syntax implementation but there's a _MASSIVE_ difference in the architecture of helloworld as a flask app and the same under cowboy; trying to get one to behave as the other makes no sense to me.
Implementing a python on beam makes no sense as to actually benefit from beam you'd need to write a lot of libraries to actually play with the environment and why would anyone bother?
And sorry but no, processes are not more or less threads. My laptop can do this:
3> processes:max(250000).
Max allowed processes: 262144
Process spawn time=3.408 (15.644) microseconds
Process teardown time=3.156 (1.552) microseconds
Preemptive scheduling is a big deal also.
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 ;)
I don't know that Python on the beam is a good idea / worth the work, but I don't think there's a fundamental issue here:
A process is more or less a thread, which Python already knows about.
Cast is just sending a message, which is erlang:msg(Dest, Msg); call is send a message plus selective receive. General receive is easy, call a function (not already available) and return the message. Selective receive is trickier, because python doesn't have a construct for matching like Erlang, so you'd have to figure out how to specify the possible message signatures you'd like to receive; plus extra work to get the make_ref mailbox marking optimization.
Monitors and links are just calling functions, and maybe being killed or getting specific messages later -- it's a VM feature, not a language feature. Same with a node.
You would have to make some hard decisions about any pythonic state though. It would be more functionally pure to pass that around as a function argument, but it might feel more like python if it was stuffed into the process dictionary. Python state shared between multiple processes/threads would be forbidden, of course. Mutability would also need some soul searching to fit into Beam's garbage collection.
EDIT to add: of course, you would need to restrict I/O to message passing -- anything with file descriptors should be rewritten to be message passing with beam ports.