Serhiy, thanks for the paraphrase of what I tried to say.  This issue has already been changed to a doc issue to explain the input/output effects of Idle's way of running user code.  I should have retitled before.  Control codes are just one of the effects that have come up on the tracker, python-list, or stackoverflow. Misunderstanding had lead to user puzzlement and even undeserved insults directed as Python.

I propose to something like the following to the introductory section of the Idle doc, https://docs.python.org/3/library/idle.html#index-0, after the feature list.

---
When Idle runs user code from either the shell or an editor window, the result is nearly always be the same as running the same code directly with python in either interactive or batch mode.  However, environmental differences can have visible effects. For instance, Idle import statements add numerous entries to sys.modules and a few module attributes to modules such as tkinter.  The line `1import tkinter; tkinter.colorchooser`` normally raises AttributeError but works when run with Idle because Idle has already imported tkinter.colorchooser. To detect whether code is running under Idle, run ``import idlelib; idlelib.run`` within a try-except statement.

More important are the input/output differences.  Python normally runs in a text console process with direct access to keyboard and screen. For code run with Idle, the keyboard and screen are controlled by the tk graphics subsystem and sys.stdin, sys.stdout, and sys.stderr are bound to objects that connect to the gui. (Note that ``print`` calls ``sys.stdout.write``.)  Here are some of the effects of keyboard and screen access being indirect.
  * Operating system (OS) specific functions that directly access the keyboard may not work.
  * The Idle shell works with complete statements rather than individual lines of code.  One can edit and retrieve complete multiline statements instead of single lines.
  * User code gets colorized. Normal output and error output to the shell get their own colors.
  * Tk supports the Basic Multilingual Plane (BMP) subset of Unicode characters.  This is worse than consoles that support supplementary planes (with appropriate fonts in use), but better than the Windows console, which only supports restricted subsets of the BMP, depending on the code page in use.
  * Tk handling of ascii control chars depends on the OS and is usually different from the text console.
---