看看基类是不是重载了 __new__ 或者有 metaclass

我怎么觉得维度对不上啊？ index: [?, 10]，但是 result [?, 1000]，怎么对的？

@noqwerty 我记得 asyncio 有方法用多进程，不过现在的 api 都很基础很难用。所以你这需求用 python 其实挺麻烦的。

@Miksztowi GIL 的存在导致文件读取的每个原子操作，线程切换的开销增大。而 shutil.copyfileobj，那是个 Python 循环，所以是不可能高效的。aiofiles 那东西在很多平台上面是多线程实现的，你可以 check 一下它的源代码。

基于这个原因，可以认为楼主的程序上多线程没救，所以 asyncio 就没有救（如果多线程有救，asyncio 还是可以用的）。而因为多线程无法使用，CPU 密集型的 unzip 就没法被 asyncio 搞定。这才导出了我的结论，unzip 是 cpu 密集型，不适合 asyncio。

至于 select、epoll 这类 I/O 复用，我觉得可以认为它们是非阻塞模型，因为它们避免了多线程模式下的 while { read } 县线程等待，和 callback 效果等同。我觉得并不一定 callback 才可以被认为是非阻塞，只要看是否达到同样的效果就可以了。

@noqwerty asyncio 主要针对网络通讯的并行化，用的是非阻塞模型。关键词可以搜索 select, epoll，了解更多非阻塞模型的事情。

@noqwerty 你的问题在于：

with open(f"{id}.ent.gz", 'wb') as f:
....f.write(data["data"].read())
with gzip.open(f"{id}.ent.gz", "rb") as inFile, open(saved_pdb, "wb") as outFile:
....shutil.copyfileobj(inFile, outFile)
os.remove(f"{id}.ent.gz")

这几行是没法被 asyncio 通过 Coroutine 并行化的，只能多线程。但是这就产生了两个问题，第一默认的 asyncio 不是多线程并行化的，第二即使设置 asyncio 多线程并行化，考虑到 GIL，Python 多线程也是不够用的。所以总体来说，asyncio 对你这段程序是不够的。还是得上多进程。

unzip 不要用 async，CPU 密集型。

其实如果你把 K.layers 里面一堆类当做 component 用，可以和别的库一起用的。手工组装 loss 也不是什么难题。

没有，很好用。Keras 只是工具，模型才是重点。什么任务都 MLP 上去做分类，这说出去才丢人。

另外这事儿看上去就像是老板眼中，那个所谓的“高人”是和他对等身份的，但是楼主这个小职员是他的下属。老板想要在“高人”面前装逼，且不说是拉拢还是纯粹想要装逼，结果被楼主破坏了，所以好面子不高兴了。这种人怼他啊，要是老板不高兴了就大不了走人呗。










当然前提是你自己的技术过硬，天下何处不留君。为了达成这样的肆意潇洒，还是尽量先提升自己的本领吧。这就是为什么大家都要读 985 的博士学位的原因。

楼上的都有毒吧？全公司只有一个懂服务器的，那就是老板也不懂啰？那就是外行指导内行啰？那争辩几句也有道理的啰？如果“高人”给出的建议不是 debian 系的（我觉得很有可能是 rhel 系的，毕竟国内“高人”嘛），难不成还要把运维部署生产等代码都重写一遍？有病吧？

你们可以认为楼主的措辞有点问题，但是你们不能认为楼主是错的。

给换是福利，不给换是本分。国行毕竟交了那上交给国家的 17% 税，在中国大陆范围内国行用户是正常用户，由国家强制力保证保修。顺便，美帝的税是商品价格之外各州额外自行规定的，所以不会在标价里面体现出来。如果你美国苹果网购了一个 iPhone，按照收货地址收税。

@charadeyouare @gtanyin macOS 独有特性：有各种和 iPad 联动的好用软件（比如 PDF Expert、MarginNote Pro、Texpad ），体验完爆 Windows 和 Linux 任何同类竞品。当然这么多年入了这么多软件，少说也得花了四位数。所以被
macOS 套牢也是没办法的，这些收费软件就是 TMD 好用。 <-- 当然我说了这么多，你可以发现很多都不是码农软件。没办法我好歹还算是个科研民工。

@charadeyouare macOS over Linux: 有好用的搜狗输入法（ Linux 那个版本是屎）、有网易云音乐（ HiDPI 版）。不怎么需要改配置，开箱即用，能不用终端就不用终端。当然，需要终端的时候也不含糊。HiDPI 支持完善，多显示器可以设置不同的 HiDPI。至今我没看到任何 Linux 桌面支持这个特性来着。

@gtanyin macOS over Windows：好用的终端，各种工具包（比如 ruby, jekyll, wget, aria2 ） brew install 就搞定了完爆 Windows。常用 Python，各类 Native 包（比如 NumPy, Matplotlib, Pandas, PIL, ...）装起来比 Windows 上容易多了。
- - - -

以上就是我被 macOS 套牢的原因。

没有被 macOS 套住的，你换哪个笔记本都可以。

像我等离开了 macOS 都不会写代码了的渣程，只好乖乖地掏出保护费。

你可以写个 run.sh

[ -f ".env" ] && source .env

读得太少，想得太多。

首先，随机数生成器得尽量减少相邻输出的关联性。这个 @alvinbone88 提到了。如果一个随机数生成器的相邻相关性太强，恭喜你，依赖这个随机数生成器的系统是存在安全漏洞，可以被攻击的。另外基于采样的各种蒙特卡洛算法在随机数生成器有相邻相关性的情况下都会 BOOOOOOOOOOOM。比如通过样本均值求期望（一种数值积分常用方法），相关性的存在会使得计算结果的方差上升，然后你的程序就跪了。

除了相关性，我觉得你的脑洞最糟糕的问题在于，你根本不知道这个“随机数生成器”生成的分布是什么。所以你既不能用它算东西（比如算积分），也不能用它产生别的分布（比如接受 /拒绝方法，借助一个均匀分布为代理来采别的分布的样本。一般用于别的分布非常难以采样，但是容易计算概率密度的情况）。根本不能拿来计算，那你这个随机数生成器到底有啥用？

@vwxyzjn 其实我也主要用 Python，不过可能我写的程序不是很业务，而且引入依赖也比较谨慎（小库基本上 copy-paste-modify-test，好处是自己的单元测试比较放心），所以没啥大问题。

@vwxyzjn All right，你说的问题确实存在，但是 virtual env / anaconda env / docker 不是都能解决你的问题嘛？我觉得总有一款合适，所以不是什么大问题。

@mooncakejs 您这话说的。为什么不把 pip + virtual env / anaconda env 当做一个整体看，那样不就清静了么？还有 @kslr 您说的这个需求，Anaconda 就支持。如果你更勤快点，Docker 也不错。总而言之您二位为什么就偏要把 pip 单独拿出来批判一番呢？

@vwxyzjn Python 社区有很多“约定俗成”，你得习惯它们，并且享受它们。譬如 x.y.z，社区标准是保证 x. 不变程序就能跑，y 不变不会加入新功能。大家写程序也会考虑这个原则，如果不能，那么这个包大概是无法成为知名的包。

当然，特殊规定是，0.y.z 不考虑兼容性。直到 1.0.0 以后才有这个规定。所以你举得例子 pandas，不巧它才 0.20 。NumPy 已经 1.0 了，TensorFlow 也是，所以可以期待其兼容性。