curses.KEY_ENTER、KEY_BACKSPACE的作用及代码检测必要性疑问

为什么 stdscr.getch() 好像永远不返回这些 KEY_* 值？ #

这是因为终端的输入行为差异极大：

• 按下退格键时，不同终端可能发送 ASCII 字符 BS（值为8）、DEL（值为127），或者转义序列；
• 按下回车键时，多数终端发送的是 ASCII CR（值为13）或 LF（值为10），而非 curses.KEY_ENTER。
  只有当终端的 terminfo 数据库明确将这些键映射到对应的 KEY_* 常量，且你开启了 keypad(stdscr, True)（让curses解析特殊键的转义序列）时，才有可能返回这些常量。但很多常见终端的配置并不会这么做，所以你大概率看不到它们被返回。

这些 KEY_* 常量存在的意义是什么？ #

它们是 curses 提供的抽象键标识，目的是让代码能跨终端统一处理按键，不用硬编码具体的ASCII值或转义序列。比如有些专业终端、远程连接环境或者特殊配置下，这些键确实会返回对应的 KEY_* 值，此时用这些常量就能写出更通用的代码。

为什么会出现同时检测 curses.KEY_BACKSPACE 和 curses.ascii.DEL 的代码？ #

先看示例代码：

c = stdscr.getch()
if c in (curses.KEY_BACKSPACE, curses.ascii.DEL):
    ...

这完全是为了兼容性兜底。
不同环境下退格键的返回值完全不统一：有的终端返回 KEY_BACKSPACE，有的返回 DEL（127），甚至还有返回 BS（8）的。代码同时检测这些值，是为了确保在各种终端下都能正确识别退格操作，不会因为环境差异导致功能失效。

检测ASCII键时检查 curses.KEY_* 有没有意义？ #

一般来说没必要。KEY_* 系列常量原本就是为那些没有对应ASCII值的特殊键（比如方向键、功能键）设计的。对于ASCII键，直接检测对应的ASCII值（比如用 curses.ascii.CR 检测回车）更可靠，因为ASCII键的输入在绝大多数终端下都是稳定一致的。
但少数极端场景下（比如某些终端把ASCII键也映射成了 KEY_* 常量），加上检测也不会有副作用，只是属于冗余的兼容处理。

内容的提问来源于stack exchange，提问作者user3310334