Leaving aside the security problems, you can do this in several ways.
You can pursue a "stateless, sort of" approach, which is simpler, by displaying a fake user prompt in CSS and supplying a textarea or input area that manages to emulate a command line. When the user hits ENTER you would get the input, send it for execution to the local shell and capture the output, then display it back formatting it as a terminal would. This could be done better in AJAX, I think.
Since you work in Python this is a related question and answer for twisted.
The above method only allows you very simple (but still dangerous :-) ) interactions. If you launched a ncurses program or any kind of interactive program which attempts to read input, you'd get immediately stuck. This is enough to run your hello.py, however.
You can improve on the method using tested libraries such as this jQuery plugin.
A more complex way would be to allocate a terminal locally (one per each user session), capture all keyboard events and "echo" them to the terminal, and read the console. You would need to know how to offer a valid terminal environment with appropriate capabilities, and then you'd need to decode the program output (complete with ANSI terminal commands) and "rebuild" the (virtual) monitor appearance, then send this "monitor" view to the client browser to be displayed somehow (AJAX, websockets...). The results would be way better, but the effort would be proportionally greater.
This latter approach (in Python) leads to projects such as this, or this, which communicates with the client through websockets.
UPDATE
All this is not needed to do what you require; you seem to need something between a module executor (not sure of this) plus a chat function (this looks mandatory).
What you need is to abstract the input and output of your program so that it can "talk" to the web browser. In this case you might run your program as a daemon (there are modules that allow daemonizing a stdio-based program). Then, the user interface (you can use the jQuery plugin) collects player A's input and sends it to the program, collects the output and sends it back to A's screen. You need to think about temporizations and asynchronicity, or turn management: player A might type in five commands while player B slowly types only one. Also, going on, you'll have to manage sessions and disconnects/reconnects of users.
Unfortunately, the "Web" world is quite different in its approaches and problems from the "keyboard" world.
