redefining stdout in imported module breaks cmdprompt on windows about ipython HOT 10 CLOSED

[ LP comment 1 by: anatoly techtonik, on 2009-06-04 12:33:54.822394+00:00 ]

from ipython.

I'd like to ask about the interaction between IPython console run in Windows command prompt and sys.std* objects. I would think there would be no interaction, because IPython console uses other means implementing iteractive io to provide features as colors and autocompletition. However for example setting sys.stdout = 3 produces infinite stream of errors.

There is a long standing issue with Unicode charcters in Python interactive console being run on Windows (http://bugs.python.org/issue1602). I'm trying to workaround by using custom stream objects, but there is some weird interaction witch IPython interactive console, see Drekin/win-unicode-console#2.

from ipython.

I would certainly expect setting sys.stdout to an integer to break things spectacularly.

From IPython's point of view, we use sys.stdout as normal, i.e. using print() (and possibly sys.stdout.write() in some places). As you've already noticed, pyreadline does things with it.

from ipython.

So things like printing colorful In[] and Out[] are done by calling some pyreadline api? But pyreadline talks to Windows console directly, so sys.std* objects are bypassed, so I don't get how their changing could affect displaying colorful propmt.

from ipython.

We write to stdout ANSI control codes for changing colours etc., which are recognised by terminal emulators on *nix systems. On Windows, pyreadline intercepts those codes with a custom sys.stdout object, and calls the appropriate Windows console functions. So if you replace sys.stdout back to sommething like the default, you probably see the effects of sending those ANSI control sequences directly to the Windows terminal.

from ipython.

That makes sense, but why can't I see the wrapper object? sys.stdout in IPython console is standard output stream and sending ANSI control sequences doesn't work with it.

from ipython.

Strange, I'm not sure about that, and I don't have my Windows VM handy to investigate.

I've just looked at our prompts code - we do just generate a string with ANSI control sequences, and pass that to input().

from ipython.

Actually, passing the ANSI sequence to input() works. The input function doesn't use sys.stdout for prompt when readline is available, but when sys.stdout is chaged, it uses the changed variant. So it's again fault of complicated interaction between readline and Python core. See http://bugs.python.org/issue17620.

from ipython.

It sounds like we should close this one and leave the Python 17620 issue you reference above for the follow-up, right?

from ipython.

With all the recent prompt_toolkit refactor I'm going to close this one which is likely not relevant anymore after 7 years. Thanks all, please reopen a new issue if needed.

from ipython.