https://datahonor.com/mppt/
搞清楚这些，基本可以到达社区标准的水平了

只是了解下，又喜欢《算法图解》的话：
《图解机器学习》： https://book.douban.com/subject/26363531/
《图解深度学习》： https://book.douban.com/subject/30221593/

https://datahonor.com/mppt/package/

建议 poetry 或者 uv ，如果依赖 conda 环境可以用 pixi

1 金币才够...

有插件可以做的: https://github.com/timvink/mkdocs-table-reader-plugin

@wsjjacky #2 感谢提醒，确实对密恐不太友好，哈哈。而且挺多图片还包含大段文字，后面打算换别的模型/PROMPT 来试试。

@gitxuzan #6 也是发布到 github page 的，这个域名就是添加一个简单的域名解析，不加也可以的。

TLDR: Material for MkDocs + GitHub Page

目前的效果: https://datahonor.com/

方案的优点:
1. $0 方案: GitHub Page 配合 GitHub Action ，无需其他费用
2. 配置简单，看文档很容易上手
3. 操作简单: 写完文档，直接 git push ，等 CI/CD 执行完成即可
4. Markdown: 简单，兼容性好
5. mkdocs-material: 好看，全面，生态好
6. 其实还有很多优点，上手用起来久会慢慢发现！

这个界面略微有点简陋，主要因为当前端只练习了两个月半...

@wildmaker #6 感谢认可！这些题目确实是需要一些概率统计的基础知识的，如果有兴趣学习可以参考下面这些书学习一下: https://datahonor.com/datascience/statistics/learn/

第一句话就没理解，Python 源码也没找到你说的这个定义...
https://github.com/search?q=repo%3Apython%2Fcpython+class+OSError%28Exception%29&type=code

@KillerMoon193 可以一起过来玩～提问题，写解答，提建议都欢迎！

@jaylong 是的，这个题其实是有政策意义的。这个题目也有个名字叫“男孩岛”，意思就是在主观严重重男轻女的情况下，男女比例还是 1:1 。原因其实很简单，生男生女的概率不随主观意识而转移，每个出生事件都是独立的，生男生女的概率又是一样的，所以最终的比例就是接近 1:1.

所以要想保证男女比例，只要避免破坏这个平等的概率就可以。这也是为什么现在政策不让进行胎儿性别的鉴定，如果鉴定出性别后做一些主观的动作(比如打胎)，其实就是主观意识真正影响到了出生事件，才会导致性别的失衡。

好像没人感兴趣哇😭

@chaleaochexist #6 https://github.com/tiangolo/sqlmodel/issues/654

参考下这个吧，如果升级的依赖有明确的 break change ，每个依赖要单独升。比如从 1.x 升到 2.x ，这里的做法是先升到 1.x 最新版，然后做好测试；然后再慢慢升 2.x 。整个是个挺繁琐的过程...

首先把你的测试覆盖度提到 90%以上，然后核心依赖逐个升级

我来泼点冷水吧，以下是个人观点。

从长远的角度看，既然要用到机器学习的工具，只要不是临时用一下就不用，你都需要学好 Python ，并且需要学好几个机器学习库的使用。

对于你说的第一个问题和观点，我是不认同的。科研卷，没错。但是学好 Python 只会让你效率更高，而不是更低。你学习语言付出的这点时间和后面折腾那些软件的时间比起来不会多很多。

对于第二个问题：基本上到了软件工具这一层(相比编程语言)，基本不会差太多。我初学时也用过 Orange ，确实还可以，但是你能做的东西就只能在他们的功能下搞，太局限了。

我能理解题主想要快速开始，快速上手，快速产出的心态，但是我还是想说这种方式就算走下去也是囫囵吞枣。即使能够短期获得一些收益，前进的空间也十分有限。

以上。

如果能看到这里，是不是可以说明我们其实没有那么急？或者说不需要那么急？那么，下面是我推荐的机器学习入门路线。

1. 学习 Python, Stanford CS106A: https://cs106a.stanford.edu/
2. 学习机器学习理论: Learning from Data ，Machine Learning in Action ，《统计学习方法》
3. 学 sklearn
4. kaggle 项目学习

@uni https://datahonor.com/mppt/package/#alternatives
现在是把 Rye 和 Uv 放在了 Alternatives ，之所以没有作为首选是感觉还不够成熟，个人使用起来很多功能还是不如 Poetry 方便。

Rye 我也在项目中用过，还算比较好用，不过项目变动还是有点多，不太适合上生产环境。之前 Rye 也被 ASTRAL 接管过去, 作为 Uv 的支撑项目(ref: https://astral.sh/blog/uv)。所以后面大概率还是要从 Rye 迁移到 Uv ，所以目前是把 Uv 标记为 Recommended.

个人还是比较看好 Uv 的，"Cargo for Python"的愿景真的有搞头。