This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients Al.Sweigart, THRlWiTi, docs@python, martin.panter, ned.deily, serhiy.storchaka, terry.reedy, willingc
Date 2016-03-10.23:24:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1457652244.66.0.245861214212.issue23220@psf.upfronthosting.co.za>
In-reply-to
Content
Part of this issue is the difference between typing a character at the keyboard, which produces a key event whose effect is determined by key bindings (some default, some added) and inserting a character into a Text widget, which does not produce an event (except, in some sense, \t and \n).  Whether or not a key event results in character insertion depends on key bindings.  The visual effect of inserted chars other than \t and \n is determined by the font.  (I believe I got the above right.) I believe some terminals treat chars coming over the wire the same as those typed.  I am not sure what the Win10 console is doing with control-x keystrokes.

>>> import sys; out=sys.stdout.write
# use direct write to avoid str(), repr() conversion of control chars
>>> out('\x03')
1  # The first char is an empty thin box in my IDLE.
>>> # type ^C
KeyboardInterrupt
History
Date User Action Args
2016-03-10 23:24:04terry.reedysetrecipients: + terry.reedy, ned.deily, THRlWiTi, docs@python, martin.panter, Al.Sweigart, serhiy.storchaka, willingc
2016-03-10 23:24:04terry.reedysetmessageid: <1457652244.66.0.245861214212.issue23220@psf.upfronthosting.co.za>
2016-03-10 23:24:04terry.reedylinkissue23220 messages
2016-03-10 23:24:04terry.reedycreate