@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 ...: 的语法 😄

@ipwx 啊，感谢提出！仔细研究了一下，这个情况其实也是出于对 gc 机制的利用。如果你试着把这个生成器实例赋给一个变量（避免 gc ），然后再调用它，像这样：
it = iter_lines([1,2,3])
for l in it:
  if l == 2:
     raise ValueError('xxx')

finally 就不会被触发。你的例子中，finally 执行的原因是生成器实例在 for 循环后被 gc 了，Python 的实现要求没执行完的生成器被 gc 时必须执行 finally，详见 https://docs.python.org/3/reference/expressions.html#yieldexpr

至于 contextlib.contextmanager，那是因为 Python 的库将 with 捕获的异常手动传入了生成器，详见 https://github.com/python/cpython/blob/7990072999b7e9b4ef6b1f6bb376d441a5a41d74/Lib/contextlib.py#L135

@zictos #22 pathlib 不会提供像 @ipwx #24 描述的文件迭代器。考虑一下下面的代码：
try:
for l in iter_lines('test.txt'):
print(l[100])
except:
pass

如果 for 循环里的语句抛出了异常，程序会继续执行，但是因为 iter_lines 生成器没有执行完，里面的文件不会被关闭。问题的根本原因是：没有办法能 自动 将外层的异常传递进入内层。这就是上下文管理器 / with 语句设计要解决的问题之一。用 with open，如果 for 循环里的语句抛出了异常导致跳出了 with 的范围，文件会被自动关闭。

如果只是一次性读 / 写，建议使用 pathlib：
from pathlib import Path
Path('test.txt').write_text('123', encoding='utf-8')
text = Path('test.txt').read_text(encoding='utf-8')

这些方法都是自带关闭文件的。