加一部 bytecode 在 ast 跟解释器之间不就好了？然后大家都生成 bytecode

同 @peyppicp 的解决方法，采取非规约化的方法对数据库进行处理，分别以 phone, email 为主键(cluster key)建表，关联 user_id。
问题还是在于用户注册时就变得需要一次性写三个表。不过这个不算是大问题，哪怕是后面进行分布式事务，这个性能也是可以接受的。

@Chingim 我看不出，所以我不买了

Mac 下的 Excel 就是残废的，你如果强依赖 Excel，那么我不建议你换 Mac。那些说用 Mac 装 Windows 的，请问你之后遇到使用 Windows 问题，去找天才吧吗？
老实找 IT，或者多申请一台，对资料进行远端备份不就 OK 了。开不了机就换一台，把东西下载下来就可以继续操作了。你下载速度总比你物理解决这些问题快多了

在于人

@codehz 你说的对，经过试验是我错了，应该用绝对路径就好了

能挂载的只有目录，文件是不能挂载的，挂载父目录吧

据我了解，这个领域好像还不需要 PyTorch 这些，好多是基于 OpenCV 做的，识别率还行。

@zappos 我由头自尾都没有谈到 GUI 的问题。

处理不了就要崩掉，你数据库连接不了。不崩掉，然后能正常运行？每个程序总有你处理不了的异常，这个时候不打日志崩掉还追求所谓 long running，那才是奇怪。

记住不是盲目追求长时间运行，或者一小问题都要崩掉。这是两个极端。

错误处理应该是，这层不能处理就应该往上层传递，最上层都处理不了了那么就要打日志崩掉。能处理的话，那么就正常处理就好了。好比你举得例子，你 handler 抛出的异常，你能处理，那么就处理啊。不能处理就打日志崩掉啊。难道你还想说不能处理的就当没事发生？

因为绝大多数人是不知道错误应该怎么处理。
举个例子，比如我要处理一下 Excel 文件，然后往里面写入一个名为报告的工作表。
第一步 Excel 文件就不存在，应该如何处理？

很多人受不能抛出异常，不能抛出错误的说法影响。好像程序一直跑着就是正常的，就是没有 bug。
其实有问题不能处理就应该往上层抛，尽量保持事发当时的环境。这样才是正常的做法。假如最上层都不能解决的，那么就应该赶紧打日志然后崩溃。阻止进一步的错误发生。

正是因为不了解错误处理，所以才那么多那么多空的异常处理，仅仅为了糊弄编译器。

当然是成本啦，一般人又用不着，你想要充钱也有啊。

你们不用智能感应的，就用文本编辑器，哪个顺手用哪个。需要智能感应的就上 IDE

@gramyang 堵不堵塞是你具体的实现，没有强制要求网络另外一端是不是堵塞一说。难道你写的服务端我用 Windows 的机器就不能调用？我还异步 IO，用 IOCP 实现呢。压根就不存在堵塞非堵塞的说法。
年轻人应该多读书，多写代码实验。而不是自己纯猜想。推荐《 UNIX 网络编程》一书。

你这样改对浏览器应该都是透明的，bio 跟 nio 的区别是一个是堵塞（ blocking ）， 一个是非堵塞（ non-blocking ），但是这个是不是堵塞都是对你服务器而言的。
浏览器看到的都是堵塞，即浏览器没有收到回应。

你这个库，写得那么好，接受捐赠也很正常。电子表格都是大 project，商业化程度很高的。我也觉得应该是别人商业化赚钱了，你就收着就好了。

淘宝就是将很多图片放内存的，没有问题，前提是你的程序不会爆内存

少穿几件衣服，天气冷开暖气都要喷，这个真是难伺候了。

@Hanggi 你这个类比是不对的，事实上应该用专业相机对比傻瓜相机，数码相机对比胶卷相机。胶卷相机是被数码相机击垮的，不是被傻瓜相机。傻瓜相机也用胶卷啊。

回到移动端，事实上对交互以及性能有要求的应用，还是会选择原生的。基于网页的应用也会占据一大部分市场份额。其实这有点像汽车市场，你总不可能拿一辆卡罗拉去拉货吧？

react native 看似美好，坑也不少。有些 bug 一样需要了解对应平台的人去解决。毕竟它不是原生的，平台商对它的支持肯定不如平台原生的。

@aoscici2000 那你现在不就回答出来了？多问自己几个为什么就好了