我看你发的 C23 Update Report，defer 和 panic 在 Unadopted Features Being Explored 里，是怎么推测出标题的？

21H2 的意思是 2021 年下半年（ 2nd half ）

FIY: /t/785258 刚好看见隔壁的场景适合用这个特性

https://www.python.org/dev/peps/pep-0584/#motivation
不怎么写 Python，看了 motivation 觉得没什么问题，解释了现有的方法有什么不足。Python 本来就吸收了很多函数式的东西，这个特性跟 Python 也挺搭的。

至于要不要用 | 这个运算符，Python 本来就支持运算符重载，语义上看 dict1 | dict2 也挺直观的，所以我觉得这个特性还不错，至少比 := 的争议要少多了。

@Elethom https://linearmouse.lujjjh.com/
只启用“线性移动”就是 ExactMouse 的效果

@98b984275a6b4591 已支持，欢迎更新到最新版

> 我理解这行代码的目的应该是想得到一个可以被 n 整除的最大值

其实是得到一个最大的 max 使得 n | (max + 1)，因为这里 max 是可以取到的。

也可以改成

max := (1<<31) - (1<<31)%uint32(n)
...
for uint32(v) >= max {

@PyCode 已增加开启 /关闭功能选项，欢迎体验。

@Zepp MOS 提供的是“平滑滚动”，LinearMouse 提供的是线性滚动。前阵子试用过一段时间 MOS （甚至还给它提了个 PR，作者似乎近期并不活跃）。可能很多人觉得平滑滚动很爽，但我还是没法适应鼠标滚轮 + 平滑滚动和滚动加速度的体验。你可以理解成 LinearMouse 是给一小撮跟我有同样需求的人开发的。

@NouveauNom 系统没法分开设置 Trackpad 和鼠标的滚动方向，触摸板和鼠标都会用到的话比较麻烦

@PyCode 以后会增加选项，如果只需要反向滚动的话，选择面还是很广的，比如 Scroll Reverser[1]（目前还是免费的）

[1]: https://pilotmoon.com/scrollreverser/

@CommandZi 抛开设备谈“自然”是耍流氓，当然我知道“自然滚动”是 Mac 的叫法，但普通的鼠标滚轮跟 Trackpad / Magic Mosue 的滚动体验显然是不一样的。

如果你的 <iframe> 里嵌的页面 cross-site 了，那么要注意 Chrome 对 Set-Cookie samesite 的默认值已经是 lax 了，HTTP 下也没法改成 none，<iframe> 页面里的 Set-Cookie 是不会生效的。如果你要嵌一个第三方（ cross-site ）的页面，第三方又依赖了 Cookie，只能通过 HTTPS + 显式指定 secure; samesite=none 。

Cookie 没写成功，没有跳转到正确的页面，就可能造成你看到的“页面不会跳转”的现象。

你确实存在误解，#6 #10 说的是对的。如果我没有猜错，你在 #20 中的例子去掉 | 0 也是同样的效果，这个优化跟 | 0 完全没有关系，| 0 是应该说是某些场景下面给 compiler 的 hint 。

js 引擎的优化多了去了，规范还规定字符串都是 UTF-16，难道 js 引擎内部真的都用 UTF-16 存每个字符串么？只要在外部看起来符合规范，内部用什么黑科技优化都可以。

@sphawkcn 是我

@CEBBCAT 认同你的观点，既然规范里明确说了是无序的，就**不应该**依赖某种语言 /某种库下有序的特定实现。

Go 1 开始刻意把迭代 map 的顺序设计成随机，也是为了防止程序员依赖某个 Go 版本实现下的迭代顺序，而不同实现的迭代顺序是有可能不同的，就会造成可移植性的问题，索性设计成随机了。

顺便分享一个近期的故事： https://twitter.com/zty0826/status/1398477411000360960

很奇怪的需求，但也是有办法的： https://play.golang.org/p/PAYLlXZjhgF

@ipwx 不同量级的数据解决方案是不同的，8*10^17 跟 10^6 量级相差巨大，最优的解决方案也不一样。

另外这里不适合直接套用生日问题的结论，因为表里的数据是已知的，表里面是否有冲突在建表的时候就可以知道。我计算的是在保证表里面的数据不存在冲突的情况下，查询任何一个 key'，其 hash(key') ∈ T 且 key' ≠ key 的概率。

@ipwx 没法保证程序**一定**正确，内存也有概率出错 :doge:

如果没有算错，任意一个字符串 MD5 跟这 100 万中至少一个发生冲突的概率大概在 2^(-108)，工程上基本没什么问题，即便安全性弱如 MD5，依旧很难找出特例。

当然，肯定是有场景不满足于这个概率的，但这种场景我想不会在意 64 MB 内存的。

https://www.zhihu.com/question/55789722/answer/146650607

teambition 是类似 #2 的做法，但是有极小概率会 fallback 到 slow path （整个分组任务重算）。

@leimao 思路在 #24 。虽然楼主并没有把需求描述清楚（只是要根据 key 查 value，还是也需要遍历），但是 100 万的量级显然可以假设是不需要遍历的，那么 key 就不需要存原始的字符串，存 hash 就可以了。

如果需要遍历，又要让内存小于 64 MB，就需要在 key 和 value 的编码方式上做手脚了。当然，楼主不介意 64 MB，只需要把我代码里对 key 做 MD5 的逻辑删除即可。