Python默认参数只能指向不可变对象，一直使用第一次new出的那个obj

第二句对了，第一句错了。

各种方案使用下来，目前来说，chruby + ruby-install 应该算是比较好的选择。

已加入，多谢🙏

支持！可惜明天有其他事情去不了。

感动，隔了这么久了还是被你挖出来了😹

嗯，是的，我就是这个意思。Python 和 Ruby 在这个问题上的处理方式基本上一样。 由于本文的主旨是 HashMap，我想我有点挑刺儿了，不好意思。谢谢你的分享，写得挺好的👍

你指的是并行吧，和并发不是一个概念啊。

不过，在Ruby和Python这种语言中，这并不是什么问题，因为根本就没有并发。

这个能具体解释一下吗，谢谢！

嗯，我只是针对那个“蛇皮走线”来说。不可否认，你提到的 GUI 的好处，也是不难理解的。我想最大的好处应该是直观。然后就是好的 GUI 应该包含一些最佳实践，类似你说的语法糖那样的说法（发现 Ruby 社区大家都很喜欢用“语法糖”这个词），比如对一些常用操作的组合封装，使之成为简单的操作、按钮、菜单，不过我想这也需要 GUI 良好的设计支持，特别是中间某些步骤涉及到网络交互的时候，就像是在处理数据库事务那样，如果 GUI 设计没有做好这些的话，我想有时候也可能会一团糟，因为网络出问题或者服务器开小差那是常有的事情。使用 CLI 去实现一个比较复杂的功能的时候，比如把很多提交压缩成一个大的提交，或者 cherry-pick 很多 commits 等，可能需要多步操作，命令行输入出错那也是常有的事情，这样子的确费时费力，而且也容易出错。理想情况下应该是两者都熟悉，简单的操作使用哪个都无所谓，哪个自己使用更快用哪个，复杂的操作使用更直观更容易的，不过出了问题，估计还是得一步一步来解决，或者干脆整个 hard reset ，然后再从垃圾堆里 cherry-pick 回重要的 commits 😓

我想 @msg7086 这里的要点估计是，使用好用的 GUI 可以“更容易”看到当前整个 repo 的进度（这个也同样依赖于使用者或者 GUI 每次提交前 fetch/pull 要提交到的 branch 的所有最新的 commits ），这样子能够尽量避免“蛇皮走线”的发生。 但其实这就像前面的兄弟说的那样，主要还是个流程控制的管理问题。