看上去没有明显的问题，不过对于任何为了改进性能的重写建议还是先 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 选项。

@ampedee 看了一下官方文档，似乎大部分的篇幅都在讲 package_data 这个保留数据文件的方式（但这个不能将文件移动到包自身路径以外的位置）。

@Rheinmetal 看了一下这两个 PEP 似乎是讲将构建的后端开放给 Poetry 或 Flit 一类第三方构建工具，而不局限于 setuptools 。

其实我苦恼的应该是找不到一个官方或者非官方的指南讲解如何在构建过程中纳入别的语言的编译（能找到的基本都在讲 C extension ）。然后 Python 的打包生态总体比较割裂，历史遗留问题也多。感觉 Anaconda 在分发预编译文件这方面的好像考虑得比较多（不过他们的依赖解析器实在是太难用了。

@abersheeran 哈哈这商业互吹。这个倒提醒我了，同时使用多个语法拓展或许还是需要接入像 https://github.com/thautwarm/moshmosh 这样的框架。

过了一遍教程，是个有意思的角度，并且作者各种情况考虑得很细（因为“融合”确实会带来很多问题）。
感觉可读性是个比较大的问题，Shell 的命令一眼看过去就像个 Python 变量（而且确实有像 ls -l 这样的歧义语句），不过一个足够强大的语法高亮或许可以缓解。
另外为了深度融合加入了许多 DSL，比如我个人感觉在命令中嵌入 Python 表达式感觉完全是徒增复杂性（@(['echo', 'hello', 'world']) 这个求值后竟然还会被隐式转为命令），与之相比 f-string 原生而不会产生任何歧义。

很高兴能给你带来启发。如果对函数式魔改 Python 感兴趣的话，可以看看红姐（ thautwarm ）的东西。另外好奇这个项目名字的含义？

粗略看了一下，想问一下为什么要为了解包额外定义运算符 ||> ，而不利用 Python 自己的解包语法呢？比如你测试里的 (1, 11) ||> range 是不是可以写成 *(1, 11) |> range ？

@abersheeran 感谢提出，这两个接口是可以覆盖挺多场景。其实我自己的主要用途还是需要封装异步的接口。
然后又仔细拜读了一下文档，发现 check_call 和 check_output （ python 3.1 ）竟然是先于 subprocess.run （ python 3.5 ）的，看来官方倾向于整合成一个高级接口，算是牺牲便捷换取风格统一吧。

@ch2 对，Python 的 pathlib 和 shutil 已经可以进行大部分的文件操作了，但主要是调用外部命令不算方便：subprocess.run 需要预设一些参数，asyncio 的 subprocess 更是缺少一些高级封装。如果拿来日常使用还是需要写一些重复代码的。

#2 提到的 Documents 这个 App 里有个内建的连接配对电脑浏览器的功能，就局域网内传输，挺方便。有进度条。我自己用传过百来 M 的文件，没试过更大的了。

@geelaw 虽然现在的 Python 里并没有这样的语法，但是其实 with 上下文里用 for 循环（即显式指定任何情况下跳出循环都需要 clean up ）还的确是个常见的模式（例如 Trio 里的 channel： https://trio.readthedocs.io/en/stable/reference-core.html#clean-shutdown-with-channels ）。如果真的是常见模式并且不考虑将语法变得冗杂，不妨提议 Python 加个 for ... in with ...: 的语法 😄