满篇的 try...except 不可取，最佳实践是

1. 如果函数出错，需要直接中止，直接在最外层捕获，统一处理，这一层你还可以加上监控之类的功能
2. 如果函数出错，可以跳过接着运行，写一个装饰器，比如叫 skip_when_met_error ，签名设计成能传入诸如 default 值这种


这样，你的业务逻辑只用考虑最正常的方式，写起来会可读很多

@stinkytofu
要不下载一个 boss ，搜一下 python 开发岗位？

@RockChinQ

提供一种最佳实践抹平程序员水平间的差异就好了 -> 不太可能，以 django 为例，且不说 type hints ，写接口用 def 还是 class 都无法统一起来。

纵观 V 站、知乎之类的问答，各类程序员（包括 Pythonista ）愿意把 Python 代码当维护的工程来写的都很少。社区自己也摆烂，type hints 和 asyncio 出了多少年了，django 至今不充分跟进。django 的结构就是大工程应用的解法，奈何 django 自己不努力，而现在流行的 fastapi 基于 starlette 改，人家就没想做大工程，定位就是出三两个接口，爽完了事。

@RockChinQ

提供一种最佳实践抹平程序员水平间的差异就好了 -

@Nugine0

docker + poetry

- 预先多做一些不同 python 版本的 base image ，甚至一些基础共有包也打进去，解决 1/2/3
- 使用 poetry 做版本管理，解决 4/5/6/8

总的来说指定的项目中可能包含多个不同的 docker file ，一份 pyproject.toml 和 poetry.lock 文件

不太懂 7 的意思。

与题目无关，生产环境不建议用 migrate ，使用 sql 文件管理，一次次更新做好版本控制，表结构的变更需要多个人过目，这样不容易出大锅

lmdb +1

black + ruff

@akaHenry

感谢回答呀！

老实说 "工具自动转" 这一步存在太多变数了，我对此不是很乐观，想了一下中间存在的问题实在太多，个人猜测如果这个方向可行，rust 社区早应该做了，而不是折中搞一个 pyo3 出来。当然肯定是希望 mojo 大佬们能够搞出来这个转换器，社区苦 GIL 久矣！

用 Pydantic 序列化，然后 __init__ 里修改，最后再 dict 导出，既清晰，扩展性又强，还能随便帮你检查 dict 中的值

昨天仔细看了 mojo 的介绍，看楼主在布道，有几个疑问能帮忙解答一下么？


> It should not be limited in its ability to introduce new keywords or grammar productions merely to maintain compatibility


我的理解是其实算是一门新的语言，python 程序员迁移仍然需要学习成本，考虑到很多地方借鉴了 rust 设计，所以推测学习成本还不低？


> We utilize CPython to run all existing Python 3 code without modification and use its runtime, unmodified, for full compatibility with the entire ecosystem


mojo 内置 Cpython 去支持 python 代码，可以理解为 mojo 并没有解决 python 的性能问题对吧？如果需要性能的领域，需要使用 mojo 语法进行实现

>We will provide a mechanical migration tool that provides very good compatibility for people who want to migrate code from Python to Mojo.


为 python 提速就是把 python 代码转为 mojo 代码？