> > Think I'll start a new post with the subject: "Globally override
> > built-in print function?"
> Don't bother. Replacing sys.stdout is the right thing to do. It
> won't interfere with the C++ streams...
-snip-
I'm not so certain. Won't the C++ host app share the same
stdin/stdout/stderr file descriptors with the embedded Python
interpreter? So there's at least the *potential* for a background
C++ thread dedicated to processing Python commands (which redirect
stdout) to interfere with, say, the main thread's log statements to
stdout. Seems like I could wind up with log statements in my
interpreter results.
As it happens, the background thread for processing incoming
commands from the remote REPL currently just queues those commands
to be executed in the main thread, so there's no contention. But
this makes some 'interesting' things possible using the remote
console:
c:\pt\celoverus\scripts>remote_console.py 192.168.1.10
Python 2.6.2 [IG REPL]
>>> from time import sleep
>>> sleep(1000000)
Because this is executed in the main app thread's context, it hangs
the host app forever. Kind of a perfect DoS attack. Not that
security is a big deal for this particular app. I'm more worried
about not being able to perform debugging tasks like this:
>>> while True:
... for obj in engine.get_objects():
... if obj.collides_with(engine.get_object(OWNSHIP)
... print("'{0}' hit the ownship".format(obj.name))
... time.sleep(5.0)
Currently, this would hang the app forever, too. Moving the
execution of remote Python commands into a low-priority background
thread would allow the host app to keep running in this case.
Anyway, that's why I've got this mild obsession with finding a way
to capture output from the interpreter *without* redirecting
stdout...
--
http://mail.python.org/mailman/listinfo/python-list
