没什么代码么, 直接听起来像是 kill 以后父进程没 wait 导致了僵尸进程, 进程标记有写它现在的状态和父进程吗

有点好奇每天还是收到北京新增十几个到三十几个的... 那边情况这么恶劣了么

@nightan #32 本身阻塞的就用 run_in_executor 吧, 丢一个线程让它玩儿去. 多看看 encode 和 aiolibs 里的经典库, 看文档灵光乍现, 看源码茅塞顿开

有想法, 但是现在微信客户端已经 3GB 了, 系统得多大一份... 我就想收发个消息, 非要给我造火箭, 还不给我 api 让我自己造...

我还真去 google 了一下... 关键词都没多加, 这问题问的还挺多, 最不动脑子的还就是楼主给的...

https://www.google.com/search?q=Python%20int%20to%20bytes

全局协程写起来有爽的地方也有不习惯的地方, 爽的基本就是全程非阻塞了, 以前多线程处理的事情全丢给 Future/Task, 整个程序基本不会因为一句代码影响其他代码(写错的情况下还是可能的... 比如错用 time.sleep). 不爽的地方就是程序不能自己识别自己要不要 await 一个结果, 害我为了兼容普通函数和协程的执行结果, 总得

result = (await result) if isawaitable(result) else xxx

性能的话, 不开 uvloop 感觉不出太明显差距

扩展名用 .pyw 试过木有?

3.8 刚出的时候 whl 都不全, 对 Windows 很不友好, linux 上还算可以, 不过新特性真没有几个让人眼前一亮的, 之前 V 友也发了性能对比, 3.6 比 3.5 提升挺大, 3.7 比 3.6 在个别组件有优化, 3.8 则没有太亮眼的性能提高. 至于说兼容性, 那种库不用也罢, 非要用就看看证书可不可以自己魔改它.

之前用 pytest 检查的时候发现, 包括 aiohttp 和 lxml 都有很多 3.8 不再兼容的语法(比如 abc 不再从 collections 里拿), 但是这些大库最新版已经兼容上了

简单的说, 看看不向后兼容的地方就知道尽量不要追新. 按照往年的套路, 任何大版本更新, 冷却它一年.

如果没有 C 库的话, 可以参考下 linkedin 当年用的 shiv, 把全部依赖打包成了一个 pyz... 不过很不优雅的感觉, 如果不能连内网 pypi, 但是你测试环境和线上环境基本一样, 可以把依赖那个文件夹打包一起带过去

如果能连内网 pypi 的话, pipenv, poetry 都可以搞虚拟环境那一套, 反正解释器还是得自己搞

不连外网还是挺头疼的, linux 上的 Python 解释器很多依赖要安装, 如果内置 3.6 倒还好, 所有依赖都下载 whl 然后本地 pip 就行了

至于其它思路... 不能打包二进制, 只能考虑 docker 了

如果非要自己实现, Semphore 的用途应该就是限定并发用的, 用法和别的锁差不多

https://docs.python.org/zh-cn/3/library/concurrent.futures.html#concurrent.futures.ThreadPoolExecutor

看看 Future 是个什么设计会帮助了解很多

当然老版本的 from multiprocessing.dummy import Pool 也依然可以用

我最近也靠这个禁用了好多读取联系人的权限... 因为安装时候读取一次就够了, 怎么几分钟读取一次, 这我有点受不了

@yuexuan #15 小项目没有问题, 不过更新还是有点频繁, 就像楼上说的文档过期问题我就遇到至少 3 次(不光 fastapi), 然后 /doc 在嵌入 sub app 的时候会访问 /openapi.json 而忽略前缀这种 issue 这两天刚遇到, 简而言之, 还是很多小毛病, 毕竟诞生不久, issue 还要人修, 功能层面各种新 feature 层出不穷, 稳定性还是有点玄乎, 但是内核层面目前来说没有什么大毛病

大项目在线上环境反正是关闭 /doc 的, 也没有什么大问题, 先体验一下吧, 我是搭配 databases 兼容多种数据库(底层用 sqlalchemy 做 orm 相关, 虽然大部分也是在用原生 sql), 配套的协程库, 有 aiolibs 和 encode 两个组织背书, 几乎遇不到我找不着库的情况了, 就算遇到了, 也是一句 run_in_executor 先跑着. 这框架真用了以后发现, 最舒服的地方就是: 以前的框架为什么不这么设计, 太神奇了. 里面很多设计给人眼前一亮的感觉, 上次这种感觉是: Bottle 的装饰器路由 和 线程隔离的全局 request 变量.
之前就半个月撸了一个体验了一把, 不过代码让我写刺了(过渡设计, 最后乱套了), 就不推荐了

遇到过一次... 魔改了最小的那个库, 后来还是有问题, 直接弃用这种不更新的库了...

尽早使用 pathlib

过长的情况按理说不会有问题, 你判断的时候打印出来看看路径是不是转义了, Windows 上默认确实是用反斜杠的, 好像和 DOS 年代什么什么规范有关系

@janxin #5
嗯, 就是想到 Spring 生态那么好的例子太少了

@frostming #7 这回是来吐槽它更新有点频繁了, 毕竟还不是 1.0 版本, 平时用上它也是找个协程环境的框架使. 顺便问个小问题, 那个 pdm 昨天更新用了下, pdm add xxx 的时候如果依赖库特别多, 偶尔一个库会因为 pypi 官网连接超时导致整个下载安装过程 crash, 下次安装又成从头开始了, 除了一个个安装依赖, 有什么办法加点超时重试么

starlette 足够稳定, fastapi 更新还比较频繁, 看他们官网上, 用 fastapi 的那几个, 多数还是内部产品时候用...
不过得看项目类型吧, golang 那么新兴, gin 就算用户多, 也没到一统江湖的地步, 不也一样上大项目

感觉不像 Django 的问题, 也没代码你让人怎么猜啊, 最无脑的给个建议, scp/wget 传输试试上下行多少秒吧

@laike9m #24
@a852695 #35
确实啊, 当年用 Bottle 的时候还没有 type hints, 一路基本上就是套装饰器然后返回 dict, 也不用我去拿 dict 包装 response
去年用 starlette 感觉一路很标准的中规中矩, 各方面设计都非常严格合理, 当时对 fastapi 的感觉就是一堆语法糖
真用上 fastapi 是今年, 这货的设计思路太美了, "真现代框架", 对 python 来说业务逻辑要思考的它大部分都简化了, 语法也省了很多

最喜欢的就是

通过类型注解自动做好类型转换, 毕竟前端 input 提交上来几乎就是字符串了, 被 pydantic 自动转对应类型 (int, Path, dict), 尤其是 pydantic + databases 操作数据库, 增删改查时候简直就是自带类型转换的轻量级 ORM
结合上面的操作, 以及提交 JSON 时候自动转对象, 写东西那叫舒服, 以前最头疼的类型验证替我兼容好了 int str 之类的互转, params 也是, 早前还觉得为这个丢性能不值得, 现在比什么都香, 让一个强类型语言做到类型的智能转换, 省了太多时间和代码了

PS: 昨晚上升级了下 mypy, 本来没报错的代码, 90% 全标红了... 最新版太严格了