@python30
文档源码在 github.com/django/django
中文翻译在 github.com/django/django-docs-translations

把它俩搞一起，用 sphinx 构建一个 pdf 就可以了啊

PDM: https://pdm-project.org/en/latest/usage/config/#central-installation-caches
UV: https://docs.astral.sh/uv/reference/settings/#link-mode

从源码编（译）了一个

https://www.alipan.com/s/bscwVNQVP9e

没有必要搞什么中文论坛了，搞了的从来也起不来

社区得是有人用的，Python 中文社区，就在这里，不挺好的吗

不知道为啥会觉得不等宽，可以拿根尺子对着一列看，如果你发现有偏移的那是 ligature

字体地址在这里： https://github.com/be5invis/Iosevka

它的设计理念是一个中文字符严格等于两倍 ascii 字符宽，所以会偏瘦

喜欢 Django ORM 试试 Tortoise? https://tortoise.github.io/

大佬赶紧把 motor 换了，不能让它再假装 aio 了

@NessajCN
@bianhui

如果觉得 rust 写的那几个舒服，说明你看重的是它们有的那些优势，而它们缺乏的东西，比如说跨环境 lockfile 你们用不到。这很正常。

所以还是那句话，看到推荐或不推荐的评论时，要想想适合不适合自己。这也是为什么我觉得问用哪个 Python 包管理器这种帖子没有任何意义。

3. 有类似 pnpm 使用硬链接减少磁盘占用的方案吗?

再说三遍

pdm 支持
pdm 支持
pdm 支持

很遗憾没人知道

如 #1 所说，没用，IDE 感知不到，但你非要骚操作的话：

import gc

d = gc.get_referents(str.__dict__)[0]
d['show'] = lambda self: 'hello? are you okay?'
'foo'.show()
# hello? are you okay?

@kuanat 说得很到位

>A 是开发者要构建的包，这里叫主包，它直接依赖 B 和 C==1.2.0 ，其中 B 又依赖 C==1.1.0 。这时候要构建 A ，那么 A 对于 C 的要求就会覆盖 B 对于 C 的要求，又因为 C 的 MAJOR 版本没有变，理论上 C==1.2.0 是同时满足 A/B 需求的。

这个 TIL 了。semantic versioning 在 Rust 上是可以强制的，甚至 linter 都能检查出 API breakage 。但对于一门像 Python 这样的 duck typing 的动态语言，有没有 breaking change 这属于一个薛定谔的问题。所以越来越多的包都倾向于使用 calendar versioning 了。这导致在 NP 问题上依然无解。

参考文章： https://frostming.com/2019/03-13/where-do-your-packages-go/

就是一开始没设计好包隔离的问题，或者说当时没有这样的设计。导入路径(site-packages)完全由 python 解释器路径来计算，可以说是一个相当 naive 的方案。

后来有了这种需求，于是有人就想到可以虚拟化解释器，建立软链接，伪装成一个独立的 Python ，发现问题解决了！但其实这种方法相当 hacky 。大家习惯了反而没有什么动力去推动包导入机制的革新了，于是就这样用下来了。

@Nugine0 你说这些 PDM 都支持啊，有什么问题？

合订本好，做周刊不易，感谢你的付出。

下期会休息一段时间吗？

请大家不要再问「有没有好用的 Python 版本、虚拟环境和包管理的工具」这种问题了。这里出现一百个答案，题主还知道要用什么吗？而且题目明明拉黑 conda 了，下面还一堆 conda 的。

要提问，请先明确使用场景。你是做 ML 开发多，还是 web 开发多，还是爬虫？
没有哪一个包管理器是银弹。你闭着眼睛推荐一个，他一用不符合场景，回头还得骂一声垃圾。

不说算法有没有用，他简历上写了，问了又不知道，这能怪谁

subprocess.Popen(['notepad', errsavelogfile])