使用队列, 使用 Future, 使用 callback, 使用协程

等你工作多年你会发现, 周围的同行里, 九成真的不是喜欢这门行业, 只是混口饭吃. 习惯就好了, 大不了跳到一个更好的氛围里去

PS: 你这操作我在国企似乎见过女同事干过...

前几天把 gitee 拉黑以后, 估计一大波人把 ECS 上默认 DNS 改掉了吧
上了快二十年网, 发现从一而终的反而是一开始在用的 114 ...
试过 dnspod baidu alibaba tencent, 在北京前两个有时候比 114 延迟还低, 但是很多国外偏门网站还是会解析不出来, 后两个用的时候总是刚好赶上他们宕机, 那种一年不一定遇到一次的让我碰上, 也是倒血霉了
所以非专业实在懒得再折腾了, 114 速度也不慢. 前几天还体验了 8888 和 8844, 发现有些国情问题偶尔得刷新一次, 也就不折腾了..

基本别指望了, 这就跟 Ubuntu server 上启动个非 headless 的 chrome 一样烦, 要开虚拟显示器, 然后让 GUI 程序投射到这个虚拟显示器里...

不知道双十一还会有一拨促销么

脑补楼主标题: 汤面是拿炒面换滴给什么钱?

@jon 扫了眼评论, 感觉在逛知乎...

@wangyzj https://github.com/linkedin/shiv 你看看不就知道了, PEP 441 里也讲的很清楚, 把所有第三方包打包成一个压缩文件 xx.pyz, 然后在有解释器的环境里就可以像 bin 一样直接运行了, 类似于
$ ./boto.pyz
然后根据参数, 在 pyz 文件里带上要执行的 py 文件的函数, 就可以整个项目打包成类似可执行文件的 pyz

懒得学就直接看上面那个 distwin 吧, 是一种协议, 允许 Python 解释器直接运行它, 并带上它里面包含的环境, shiv 后期也把局部环境被全局弄脏的 bug 给修复了, 变成了局部优先, 所以尽量用新版本

还有个小地方要注意, 虽然 Python 代码是跨平台的, 但是如果遇到需要编译 C 文件的库, 就没法跨平台了, 毕竟编译的玩意是不兼容的

@lxk11153 还真是... 算了, 无力吐槽, chrome 设计师再差, 也比微信强多了

@lxk11153 我是引用的... 原帖也给你了. 不过我更新了 78 以后, 地址栏里依然有 https 呢, 感觉那个帖子说的事情没发生

@chengxiao 你这个结论是最近的么, 之前我还真在 Windows10 上打包了给 Windows7 的人用过, 是正常通过的.

不过你说的这个情况在 3 年以前, pyinstaller 还不稳定的时候确实存在, 所以每次打包为了兼容性, 我会把需要的所有 VC100.dll 什么的一起带上, 以及 pyqt 打包会缺失的 platform.dll 也都带进去, 那年代为了兼容性真的煞费苦心了.

前段时间问过群友, 说这些 bug 在新版本 pyinstaller 都已经自动兼容好了

@omph 不用客气, 之前也做过相关操作而已, 部分历史代码可以看 https://github.com/ClericPy/distribute-python-on-windows 不过不知道还可以用么, 这库的主要操作就是去官网下载 embed zip, 然后解压缩, 然后打包 shiv , 然后生成一个 run.bat 用来执行, 你稍微改改就好了


@wangyzj 两码事, shiv 的用处接近于虚拟环境的 zip 化, 打包成单个 pyz 文件以后, 整个环境的所有第三方依赖就独立于全局环境了. pyinstaller 只是一个编译工具, 而且是把解释器一起编译进去的, shiv 是不带解释器的, 所以 pyz 文件很小

以前学习的时候实现过同步代码里使用协程

from torequests.dummy import Requests
req = Requests(frequencies={'p.3.cn': (2, 2)})
tasks = [
req.get(
'http://p.3.cn',
retry=1,
timeout=5,
callback=lambda x: (len(x.content), print(req.frequencies, flush=1)))
for i in range(4)
]
req.x # or [task.x for task in tasks]
result = [task.cx for task in tasks]
print(result)


这里的 cx 是 callback 的返回结果, 如果没有 callback, 直接使用 task.x 就有了, 和普通协程比, 性能损失倒也不算大. 不过还是习惯在全局协程里用

还挺大的, 和我家里的都不一样.
大多数家养蜘蛛都是益虫, 而且会躲着人, 不会有什么坏处的

长这么大第一次见送头皮的

@Achilless 协程的切换是用户主动操作的精确切换, 没有太多多余开销, 而且内存也比较省, CPU 效率更高, 至于并发, 没什么压力, 可以去 Google 看看 Python coroutine 的相关文章, 内部实现比较复杂, 但是对用户的接口依然是 Future 那套, 不是太难学

去看 linkedin 的 shiv 库, 会打包成一个 pyz 文件, 以前我就是这么让别人安装 Python, 其他源码加依赖都是用我这个 pyz
下面这个是打包 Django 成 pyz 的方式
https://shiv.readthedocs.io/en/latest/django.html

如果把官方那个 Windows 嵌入式绿色版解释器一起给对方, 甚至连安装 Python 都不需要, 这两种方式我还真都琢磨过

然后还有 close 和 join 忘了说
前者的意思是进程池已经关闭, 如果再添加新任务, 会直接抛错, 而不是真正关闭了所有进程
后者意思是, 主线程 /主进程 整个阻塞住, 直到进程池里的任务全都完成

你想直接拿那个结果, 别 join, 直接对那个提交后得到的对象使用 get 方法

def apply_async(self, func, args=(), kwds={}, callback=None,
error_callback=None):
'''
Asynchronous version of `apply()` method.
'''
if self._state != RUN:
raise ValueError("Pool not running")
result = ApplyResult(self._cache, callback, error_callback)
self._taskqueue.put(([(result._job, 0, func, args, kwds)], None))
return result


1 2 3 基本都有办法的, 在一切皆对象的 Python 里, 几乎所有玩意都能自省
看看源码去吧, 一点点说太麻烦了
比如 apply_async 方法的返回值就是 ApplyResult 对象, ApplyResult 对象里可以判断是否完成以及立刻取得结果
Apool 的 self._pool = [] 这里也可以看有多少
多看源码吧


友情提醒, 你这个用法已经过时了, 现在多进程多线程的池都建议使用 concurrent.futures 里面那俩, 借助很多语言都在流行的 Future 概念, 可以在同步代码里面把异步操作简化. 尤其是借助 callback 方式(虽然你上面的代码也可以用回调)也算不难理解