应该是 15.4 的新 bug 。有几十个闹钟并每天手动开关的人表示几乎每一次都能复现。

谢谢分享！试了一下发现 iOS 自带的地图以及其他 App 内嵌地图也可以，但是是上划放大，下划缩小（谷歌苹果存心作对么……）然后双击拖拽缩放应该只有地图类支持了，像是 Safari 或者照片就不支持。

@loginv2 @weixiangzhe @InDom @Opportunity
谢谢各位推荐工具，不过这本质上和我提出的方案一类似。如果我想不到其他办法，应该就引导用户安装插件然后载入我的 CSS 了。

@xiangyuecn
这个办法其实蛮有意思的。虽然可以写个一键添加这样的书签，不过用户每次在每次页面刷新后都得先点一下书签，有点麻烦😂

Cloudflare 这个免费临时隧道就是解决这种问题的。单可执行文件，零配置即开即用，然后把生成的临时网址发给对方就行了。
https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/run-tunnel/trycloudflare

关键词：package_data
另外提两点
- .egg-info 文件夹是打包时生成的，不应该提交到 git
- config.cfg 里有一个单引号没 escape

赞耶，节省了为每个项目写一个安装脚本的功夫。我之前维护了个重定向至特定系统架构的可执行文件下载链接的服务，这个方案完善得多

我对数据库不熟，不过我猜对于很多数据库并发写是不会有性能提升的，用单线程就可以了，但你可能需要 batch / bulk 操作，用来一次性插入数十条、数百条数据，而不是一次插入一条。

又看了一下你贴出来文件的部分，你是不是就两个大文件（就是说不是大量小文件），那文件 IO 就基本不可能是你的瓶颈，你看到磁盘读取没跑满很有可能是你下游的处理速度没跟上。

多进程和协程，感觉你自己也总结出来了。协程得用在有长时间等待系统调用 (syscall) 的地方（比如网络、子进程、定时任务）。CPU 密集的操作得用多线程或多进程，但在 Python 里有 GIL ，就只能用多进程。

看上去没有明显的问题，不过对于任何为了改进性能的重写建议还是先 profile 一下，看看瓶颈到底出在哪个调用上。

然后异步文件 IO 不是为了提升性能（降低平均延迟）的，而是为了降低尾延迟的，参见： https://trio.readthedocs.io/en/stable/reference-io.html#background-why-is-async-file-i-o-useful-the-answer-may-surprise-you

核心要义是利用这些软件调用脚本（ bash 或 Automator ，macOS 其实开放了很多方便的命令），比如说 Karabiner Elements ，就是用它 Complex modifications 里的 `shell_command`（需要修改它的 JSON 配置文件，我会放在最后说）

我自己用了好几年的配置主要是用 Karabiner Elements 做键盘映射，ControlPlane 做情景感知，然后触发的都是脚本指令（ Hammerspoon 几年前试过一下，弃用了，感觉 CPU 占用太高了，而且除了窗口排列相关的命令都可以用 Karabiner Elements + 脚本代替，不知道现在更新得怎么样了）

举几个代表性的例子：

Karabiner Elements：
右⇧ + d： 打开下载文件夹
右⇧ + delete：熄屏
⌥ ⌘ + F2(亮度+)：禁止休眠并弹出一个常驻通知（点击通知以取消）
F3(任务控制) 和 F4(launchpad) 分别被映射为蓝牙和 WI-FI 的开关了

ControlPlane:
系统休眠前（合盖后）关 WI-FI ，系统唤醒后（开盖后）开 WI-FI
（ ControlPlane 的作用相当于 iOS 快捷指令里的自动化，场景非常广，甚至有诸如当连接到特定显示器、摄像头光线传感器之类。可惜作者不主动维护了，Big Sur 还能用，就是不知道未来哪个 macOS 大版本就用不了了）

Karabiner Elements 的高级设置可以参看 https://karabiner-elements.pqrs.org/docs/manual/configuration/configure-complex-modifications/ 。先下载它的一些现成的配置，然后再找到它的 JSON 配置文件自己改。脚本命令的话，把自己的需求上网搜一下基本都能找到。

上下文管理器是（在字节码层面）被设计为必须将段落内容执行且只执行一次的。你这个需求可能得写个装饰器，然后把需要计时的片段放在一个被装饰的函数里。

@lisongeee 就我所知应该是没有一站式解决方案的（有过像 github.com/nvbn/py-backwards 这样的尝试，但没有持续更新）
在 Python 社区里更常见 backport package 这种零散的方式，比如自带的 __future__， 而在 PyPI 里可以找到把 contextlib, contextvars, data classes, 甚至 f-string 等新版本功能带到旧版本的包。

@janxin 哈哈是，那些我留意到的兼容代码我确实有写注释。不过对于足够老的代码就行不通了，比如说我写第一版代码的时候 Python 的最新版本是 3.7 ，我是不能预知 Python 3.9 的新功能的。或许代码老到一定程度就是维持现状或整体重构两条路了。

@Pagliacii 这个似乎是写给用我写的库的下游用户看的。不过 Python 标准库确实也会给 DeprecationWarning 。

@Trim21 好东西👍，试用了一下，这个似乎只是志在覆盖那些 100% 确定可以改写的代码（所以甚至没给只检测不修改文件的 dryrun 选项），而且大多数是语法的规则，像我提到的那种需要猜测代码意图的复杂情况可能还是比较难实现。不过对那些需要大面积改写的老代码做初筛还是很好用的。

之前遇到下载速度停留在十几 kb/s 的情况，查到对应的 GitHub issue 发现是个 bug 但开发者很久没管了。又看到 yt-dlp 这个活跃维护的分支，用了感觉不错，现在转投 yt-dlp 了

@CharlieYu4994 @learningman
就目前来说，如果你需要的文件名在不同的 release 中都是一个固定的字符串，那推荐使用 GitHub 官方的直链。但有些仓库（比如 kcptun, frp ）的作者会在文件名中包含版本号这种每个 release 都会变化的部分，那我这个的正则匹配还是有用武之地的。

顺带一提，开始写这个东西时，GitHub 还没有针对 latest release 的文件直链。

感谢作者，用了一年多了，用来做监控告警和耗时命令执行结束的提醒，非常稳定

就我了解，gevent 最初要解决的问题是提供一个高性能的异步库，因为那个时候 Python 没有语言层面上对异步的支持（ async / await 和对应的生态）。而现在的情况是，Python 3.6 左右时原生异步就比较可用了，3.8 时内置 AsyncIO 库的设计和性能也跟上了，所以新项目基本都采用 AsyncIO 了。毕竟 gevent 本身在当时有限条件，整个实现方式就是个 hack：monkey-patch 在一些边角情况下会有各种奇奇怪怪的问题。

实际上 gevent 尝试解决一个更大的问题，重写了 Python 解释器的底层，有兴趣可以查查 stackless Python 。

另外也像 #4 楼说的，异步的需求一般都跟网络相关，而对于这部分的应用很多人都转 Go 了。

@enderftt
#5 楼的第一种写法是 Python 3.9 新增的语法

如果要兼容 Python 3.9 以下的版本，个人比较推荐 #4 楼 或 #7 楼的 immutable 写法。

@Rheinmetal 原来如此。看了一下 Poetry 好像就把额外的构建步骤放在 build.py 里了。我还是倾向分发已经编译好的二进制文件，毕竟这也是 wheel 的初衷。

@frostming 感谢点拨，用上了 build hook，然后加上了 --plat-name=manylinux1_x86_64 选项。