你不能那样做，因为我讨厌你

Python REPL exit 行为

• 争论的焦点是，在 Python REPL 中输入 exit 和 exit() 的区别。
• 有些人认为当前的行为（通过 repr(exit) 打印提示字符串）显得居高临下：解释器能看出你的意图，却拒绝退出。
• 另一些人则认为这是一个合理的折中：
  • 保持语义一致（函数不加 () 就不会执行）。
  • 避免为特殊情况开后门，否则会破坏依赖 REPL 一致性或依赖 repr() 无副作用的工具。
• 讨论中提出的替代方案包括：
  • 仅在 REPL 中对 exit 做特殊处理。
  • 同时打印函数的 repr 和一个提示。
  • 使用警告或仅限 REPL 的提示，而不是改动 __repr__。
• ipython 更友好的处理方式（输入 exit 就能直接退出）被用来证明，完全可以有更好的用户体验。

---

“按我所想做”与严格性

• 一方观点：工具应该对清晰且无歧义的意图作出响应（例如 exit、-? 表示帮助、当存在 --foo 时使用 -foo）。忽视明确意图会让人感觉像故意刁难，也浪费时间。
• 另一方观点：DWIM 行为会成为规范的一部分，引入歧义，而且一旦猜错，失败可能更糟（例如分号插入、浏览器对 HTML 的宽容处理）。
• 许多人认为，提示和清晰的错误信息优于自动修正。

---

Rust 工具链与不稳定特性

• rustfmt 的 wrap_comments 和 cargo vendor 移除的 --no-merge-sources 标志是争议焦点。
• 批评者认为：把简单、明显有用的功能放到 nightly 才能用，或者移除参数却给出无帮助的信息，感觉就像“工具知道我想要什么，却拒绝照做”。
• 支持者认为：格式化和 vendor 行为有很多棘手的边界情况；标记为“不稳定”可以避免在 diff 和 CI 中引发大规模变动，而实现本身也并不简单。积压任务和优先级限制同样是真实约束，尤其是在志愿者项目中。
• 有人觉得 nightly/stable 的划分过于粗糙：一些小的实用函数或格式化选项不该需要 nightly。

---

CLI 交互与帮助标志

• 对那些以下行为反复感到恼火的工具：
  • 拒绝 -? 或 -h，却又建议使用另一个帮助标志。
  • 强制严格的选项顺序（git log --stat directory）。
• 许多人倾向于接受多种帮助调用方式，并采用更宽松的解析，尤其是与帮助相关的操作。

---

默认值、“不要糟糕”按钮与同理心

• “不要糟糕”按钮：默认关闭的选项，却能让软件表现得更符合大多数用户的预期，而且没有明显缺点。
• 这里存在张力：
  • 通过更好的默认值和提示改善新手/普通用户的体验。
  • 又不破坏现有用户或高级用户的工作流，也不让实现变得过于复杂。
• 一些评论呼吁更多同理心、更清楚地说明做出这些决定的“原因”，并更重视 CLI 和 API 的交互设计。