协程的意义在意执行多个没有上下文结果依赖的“不相关”的任务的时候会让这些任务并行执行，同时又不需要担心线程的状态管理，以此达到运行效率的提升。
但是，有一种情况下协程并不会提升效率，理论上反而会降低效率（因为线程切换的代价）。

async def run(tasks):
all_results = []
for task in tasks:
result = await execute(task) # the only one await
all_results.append(result) # append logic result of execute, not task itself

return all_results

不是特别好的一个例子。只有一个 await task 的话，后续操作又需要拿到结果才能继续，相当于同步的 join 卡在了 caller 所在的线程，没有异步的意义，所以会更慢。当然，基于上面的例子要优化也是非常简单的，不写了

#21 #22 如果我看到加 2 这种做法一定往死里打
#23 加 Ex 一般是定义两个相同功能但参数列表不同的成对方法


如果是功能和之前的 getUsers 基本相同，参数列表也相同，建议不要写一个新方法出来，直接在原来的实现上改写。
如果功能不相同，建议不要加任何“通用型”等无意义的后缀，直接 getXXXUsers 之类的，以示区分。

说个野路子：我现在的 1Password 的数据就是存储在 Dropbox 里的，iOS 版的 1Password 应该是集成了 Dropbox 的 API/SDK，所以直接直接从选择使用同一个 vault。同样的道理，可以直接在 github 上找一个开源的 markdown 编辑器的项目，把 Dropbox 的 API/SDK 也集成起来编译到自己的手机里就好了。

头一次见识这样的“附属表”设计，真是“涨姿势”了

请教：不是很理解“通过(B)跳转登录到我们其他的 server”要如何操作，是在 B 机器里直接存入了 ssh keys 还是担心别人通过 ssh 密码爆破？

很尴尬：不可以。
Files 虽然可以接入 Dropbox, OneDrive 等 File extension 的外部文件管理，但是在其他 app 里面只能选取和分享，不能编辑后写入。
类似 Documents 的 app 虽然可以从 Files 里面导入文件，但是写入文件的操作只能是存储到当前 app 在 Files 里面的 sandbox 文件夹，不能和其他 app 交叉。
除非 Dropbox，OneDrive 官方支持编辑各类文件的操作，但是希望渺茫

如果是静态资源的话就加 CDN，如果是写操作的 http 操作应该加服务器分区，后端额外部署一套服务来判断用户 ip 离哪个分区最近。
说错了请更正？

@fml87 瞎说啥大实话，还给不给年轻人留条活路了。没有资本的加持技术就不会迭代，技术不更新资金怎么会来。

都是讨生活，只要自己喜欢做，理解资本的本质是什么，做了又何妨？群体协作的有用功从来都没高过，从不给予过高期望，接受现实，不要和个体作对比。大江东去浪淘尽....

烂得掉渣，卸了

如果只是想做一次性 clone （不需要拉取更新）的话，可以加上--depth 1 的选项，可以让需要 clone 的 git objects 少一个数量级，对 commit 数量比较大的仓库尤其明显。间接提高速度了，我是从一些包管理工具封装的 git log 学到的。

utterances 是真心舒服，立马替换掉了 Disqus。

https://xingheng.github.io/

不过话说回来 type hint 还是有意义的，python 写多了自然会慢慢发现这个问题。
type hint 本身和类型检查不冲突，但是在使用 typing 或者没有用好 typing 的时候尝试类型检查一定是非常糟心的。

就楼主写的 sample function 而言，加或者不加类型判断都是合理的，调用出错了也不是这个方法本身的错，应该由调用方解决。
类型判断本身是有意义的，比如如果上面方法在实现的时候是接受 str 和 list/tuple 多种数据类型的时候，类型判断就变成了逻辑问题了。

找到了一个还算匹配需求的工具：just，链接： https://github.com/casey/just
直接基于 sh 运行，没有注入，全平台。
@ps1aniuge

~/.trash/ # :)