We're sunsetting PodQuest on 2025-07-28. Thank you for your support!
Export Podcast Subscriptions
cover of episode #410 Entering the Django core

#410 Entering the Django core

2024/11/18
logo of podcast Python Bytes

Python Bytes

AI Deep Dive AI Chapters Transcript
People
B
Brian
Python 开发者和播客主持人,专注于测试和软件开发教育。
M
Michael
帮助医生和高收入专业人士管理财务的金融教育者和播客主持人。
Topics
Brian 讨论了 Carlton Gibson 关于 Django 核心与插件之间平衡的观点。Gibson 强调了 Django 核心保持精简的重要性,以及插件生态系统如何增强框架的活力。文章探讨了 Django 的可持续性问题,指出核心团队规模小,维护这样一个被广泛使用的框架是一个挑战。Django 核心功能更新缓慢,而插件可以更快地迭代和发展,这为框架的长期发展提供了灵活性。文章还提到了 Django 核心团队在支持插件生态系统和避免扼杀竞争之间需要找到平衡点,并指出为初学者提供插件选择指南是一个挑战。

Deep Dive

Chapters
Carlton Gibson discusses Django's core versus plugins, sustainability, and the release cycle, emphasizing the importance of a small core and a vibrant plugin ecosystem.
  • Django will be 20 years old next year.
  • The core team is small, with only a few people maintaining the framework.
  • The ecosystem is built on a plug-in architecture, allowing for a wide range of functionalities without bloating the core.

Shownotes Transcript

您好,欢迎收听 Python Bites,我们将 Python 新闻直接传递到您的邮箱。这是第 410 期,录制于 11 月 8 日星期一上午 7:37。

Ual,是时候开始我们的直播了。我们在这里。我是 Michael。

dy,我是 Brian。

本期节目由我们赞助,我们的课程、pytest 课程等等,查看链接,它们都在节目说明中,您可以在播放器中找到。我们有一个标准的介绍。Brian 首先发言,然后是我。但是你知道什么不是新的吗?你为我们创建了一个 Python Bites BlueSky 账号。

BlueSky 怎么样?

你仍然可以在 Mastodon 上关注我们,我们仍然在那里非常活跃。但是,如果您是众多从未真正使用过 Mastodon 但决定使用 BlueSky 的人之一,那么请访问 Python Bites BlueSky 社交账号。这是一个与我们所有人保持联系的起点,仍然可以在这里关注播客。

关注 Brian,他的链接在个人资料中。你也可以在那里关注我,你可以在 Mastodon 和 BlueSky 上关注我们,享受 BlueSky,对吧?你觉得怎么样?

我认为……我认为默认体验很好。我也喜欢它。我喜欢默认体验非常好。我在 Mastodon 上使用它。

我喜欢 Mastodon,但我不得不弄清楚如何在 iPhone 上使用它,它运行良好。它是一个非常舒适的东西。但这花了我一段时间,因为……我不知道是否有默认的客户端。

它不太好。是的,有一个默认的。但我试用了它一段时间。

我也切换了它们。

是的,是的。许多人想迁移到那里。作为社区的一部分,那里有很多熟悉的面孔。我们在节目中谈论的许多人都非常活跃在那里。

所以……我不知道,它在发布时没有添加该功能。如果你以后做到了。

只是让大家做好准备,准备好接收我很多来自手机的推文,我正在研究它,也许……

在我看来,但在社交媒体平台上公开批评他人的推文是不好的做法。你知道,这只是……好的。

你……但是,关于介绍,查看直播节目。我们不知道它是什么时候。

通常是星期一。

我们通常说的是星期一上午 10 点。但最近我们通常是上午 7:30。

是的,我的错。但我总是能赶上。

没问题,我会弄清楚时间的。但你总是可以在一个节目结束时找到下一集,所以我会带你去 YouTube。最后,来自 Brian 的手工制作的、精美的每周节目笔记摘要?

是什么让你……让我们谈谈 Carlton Gibson 一下,他是 Django 核心成员,我认为……

他辞职了,他是 Django 核心成员。

聊天……Django 聊天……很棒的……另一个播客……但是,他的……他对 Django 的想法……这是一篇很长的文章,但写得很好。它谈论的是 Django 核心与 Django 插件,以及 Django 的寿命等等,以及是否包含电池等等,以及如何维持它。

所以,其中一件事情是……我想我忘记了 Django 明年将满 20 岁,20 年前……嗯,那是很长一段时间。所以现在应该是 19 岁了。嗯,那是很长一段时间。所以,可持续性问题之一是……有这样的说法,它是一个适合有最后期限的完美主义者的 Web 框架,它也是一个包含电池的框架,但不是太多电池。嗯,核心很小。

嗯,然后还谈到……很多人理解 Django 的强大之处不仅仅在于核心,还在于你可以快速使用核心构建一些东西,但所有插件都可用,因为生态系统……是一个插件架构……那么它在谈论什么?很多人没有意识到只有几个人在工作。我的意思是,对于使用 Django 的人数来说,团队规模并不大,大约是 1.5 个人……我试图找到它……无论如何,我们得到了这个。有 1.5 个人……

我们可以直接进入这个。这是……

很棒的图片。

Brian 的参考。太棒了。

是的,动动脑筋。我喜欢它。好的,Brian,我们今晚要做什么?我们每晚都做同样的事情,Pinky,尝试将我们的包放入 Django。嗯,这是 Ilaria。

呃,这个想法是很难将特性添加到 Django 核心,但也许你不想……呃……有人记不起属性了,但有人提到汽车是插件的坟墓,这有点苛刻,但人们理解,如果你的特性在核心代码中,它不会经常改变。然后,如果他们……他们……他们进行……他们进行弃用发布,大约每两年一次。所以,如果你想弃用一个特性,那就是两年。

如果你想添加新特性,这是一个缓慢的过程。有很多测试需要进行。如果它是一个插件,那么添加新特性会容易得多。而且如果我们回顾一下,我的意思是,像我们可能那样思考未来。

这里的一个例子是……我不会尝试去找到它,但一个例子是 XHTML。是的,没错。退出菜单,超级棒。

很多人都在使用它,它应该成为核心代码中原生支持的一部分吗?好吧,如果我们回顾几年前,它就像 React 或者其他什么东西,应该原生支持 React 吗?很高兴他们选择了不这样做……现在……XHTML 可能是下一个……几年后我们永远不会知道。

嗯,还有……是的,有很多例子。呃,Django REST framework,我有点忘记了这不是核心功能。这是一个……它只是一个非常流行的插件。但是,像 Django Ninja 这样的东西……也很棒,如果 Django 框架是核心的一部分,它可能就不会存在。所以生态系统很棒。

但是,这里有一个需要注意的地方,我喜欢这个讨论,关于 Django,甚至 Django 网站,团队也不喜欢……选择每个人都应该使用的插件或获胜的插件,因为这有点像引入一个装饰器,这会减少生态系统的竞争。但与此同时,对于初学者来说,很难跳进去说,好的,那么我应该使用哪些插件呢?当然,没有一个适合所有人的解决方案,但我认为……我想我欣赏这个讨论,关于我们如何支持生态系统而不扼杀生态系统。无论如何,嗯,我……我……我看到这个和 pytest 之间也有关联,因为 pytest 也有同样的问题,即有一个核心,并且核心代码中有一些我希望不存在的东西,还有一些不在核心代码中的东西,我认为可能应该在里面。所以每个系统都会有这些观点,以及如何处理它们,无论你是否批准一个插件,这对于我们每个系统来说都是一个令人不安的事情。

无论如何,这是一个艰难的平衡。所以,观众中的任何一位,Penny 说,很高兴看到 Django 现在有了任务功能,不再需要 Celery 了。

这是对的。它也有一些能够简单地说,不,我们可以让事情运行起来。我们不需要像……也许只是……我认为我有一个线程,你知道的。是的,另一方面,这是一个永久存在于 Django 或任何东西上的负担。

是的,是的,另一个有趣的漫画是,这是关于你如何看待开源应用程序的维护方式,有一张图片,上面有很多人一起闲逛,在白板上画画,聊天等等。而现实情况是一个人在地下室说,再处理一张工单我就去睡觉。是的,我完全同意。

让我们进入未来,好的,我们要去 FuturePool。

这个来自 Pat Decker。谢谢,Pat。所以,这是一个关于允许你进行多进程类型工作的库的有趣想法。但是,对于 asyncio 来说,挑战之一是你可能会压垮系统,它没有……我认为你会说它没有回压。

让我举个例子,如果你在普通的程序中,你在块中调用一个函数,比如我调用一个数据库查询,它会一直停在那里,直到数据库返回响应,对吧?如果数据库很忙,这会减慢调用数据库的那部分代码的速度,对吧?调用数据库的那部分代码会阻塞整个系统,减慢它的速度。但是,对于 asyncio,你只是不断地向它抛出更多工作,然后继续进行,所以你可以为它创建更多工作,对吧?

所以,asyncio 的挑战之一是你可能会压垮系统,如果你知道,嘿,我们真的只能处理 10 个并发请求。但是,如果你超过了这个限制,就会出现问题,再次设置这个限制也是一个挑战。所以,这就是 FuturePool 所做的,它很酷。

这是一个小的用例,因为他们使用它的方式,但它仍然被称为……在多进程中,这是传统的……我创建多个进程,因为 Python 有 GIL,我们不能真正进行计算并行。所以我们要这样去做。

所以你可以做的是说,嘿,也许我们只有两个核心,或者我只想使用两个核心,或者无论你说什么,使用两个工作进程的池,最多只能有两个进程开始处理你拥有的所有请求,但一次只处理两个,一个完成后,获取下一个,然后继续进行,直到你完成,对吧?FuturePool 的想法就是这样,但对于 asyncio 来说,你可以说,使用一个大小为……你想要的 FuturePool,然后你可以 await pool.map,对某个工作块进行一些函数操作。

但是很有趣,对吧?这样你就可以停止。调用者不能再发送超过 asyncio 限制的数量。

那么为什么我说这是非常有限的呢?为什么?它为什么可以更好?它如何才能更好?所以,它是一个你在一个函数中创建一次的小型本地对象。

它也执行工作,你可以说,运行这个任务异步地。是的,你必须在它上面使用这个生产者模式。是的,这不是普通的编程方式,不像我调用这个函数等待那个,或者调用那个函数等待那个。

如果有一种方法可以让你说,对于这个程序或这个线程,或者也许不是理想的,但也许甚至是对于这个事件循环,我不在乎工作是如何到达它的,一次最多只能处理五个。所以,如果一个 Web 请求启动了一些东西,太棒了,它会进入这个东西,它被限制为五个并发请求。如果我说 await 某个调用,它也参与这个池化节流限制类型的东西。但是,据我所知,asyncio 没有这个概念。所以,也许这对于某些人来说可能很有用,并且可以激励某人创建一些真正有趣的东西……

在运行时创建它可能有点危险。但是,是的。

它不存在……

你以前用过类似的东西吗?有时是……

是的,我使用过 asyncio-unchained,它非常有趣。这当然是可以做到的,因为它的作用是将所有异步请求转换为单个循环中的单个……

后台线程。所以,是的,也许……我只是认为更多的是……你想要向这个系统提供工作的方式,并且让它……异步地执行,然后……

更好……所以,是的,是的,这将是很棒的。问题是,我认为它真的需要一些比……可以为……构建包的人更低级的……是的,它需要成为 Python 本身的一部分。它有 uvloop 作为……

是的,作为其中的一部分……我们又来了……它需要成为循环本身的一部分,几乎就像工作是态度一样,对吧?但是你知道,uvloop 可以替换普通的 asyncio 循环,这通常是一个好主意。不可能。但是,也许……也许是这个级别你需要工作的。也许我们可以看看这个领域,看看我们可以做什么,因为这将非常酷,比如 asyncio-unchained,处理所有你想要抛出的并发请求,但它只会将它们传递给……或者你执行的更多,一次处理一个,或者类似的东西……是的,无论如何……哦,人们可以去 FuturePool 并查看它,也许为你的……

项目使用它……这很有趣。我说 uvloop。而且,uvloop 有循环。哦,不。uvloop 在 uv 之前就存在了。

uvloop。那是对的吗?你真的花了很多时间。我知道它存在了多久,但至少三年了,至少八年了……哦,对不起,是的,至少八年了,所以比 uv……

更长……

好的,是的。

嗯,我想去看一篇名为《在新的应用程序中不要返回命名元组》的文章,这是一个很简单的事情,但它很好地提醒了人们。首先,我要感谢Brett Cannon使用术语“API”,指的是模块、类或包的API,而不是Web/REST API。API这个术语在互联网出现之前就已经存在了。我们不是在谈论REST API作为Web API,而是在谈论所有函数、方法或类的API。

命名元组很棒,因为你可以一行代码就说,嘿,我有一个点,它很酷,为什么我返回命名元组呢?因为像点这样的东西,很明显人们可以访问X、Y、Z或其他任何东西。在某些东西中,比如点,这很容易做到,你知道,或者获取我的位置,你知道这是一个XY坐标。所以例子可能在那里,但是为什么你不想使用它呢?他认为,我有点同意,用命名元组实现一些东西很容易,但是现在你必须同时支持基于索引的访问(像元组)和基于名称的访问(像字典)。所以同时拥有索引访问和名称访问可能会很麻烦,我认为我见过很多人假设它是一个命名元组。人们可以使用名称,但它也是一个元组。

所以你可以使用它,你可以切片它,你可以做各种事情。所以,这只是为了避免使用类,但是现在类更容易了。所以有一些命名元组的替代方案。

你可以返回一个数据类,这可能是我会抓取的东西,可能是数据类或字典,字典也可以正常工作,或者TypedDict。TypedDict的一个好处是,你也会得到编辑器的支持,因为你在里面有类型。然后是对我来说比较新的东西,我必须尝试一下,那就是SimpleNamespace,它使我们能够访问名称。但是它不是可索引的。我还没有尝试过SimpleNamespace,所以必须这样做。

我也没听说过SimpleNamespace,而且我实际上也没有真正使用过TypedDict。

它们都是不错的选择。我有点加入了数据类的潮流,现在经常使用数据类,因为我认为我需要更多地考虑它,但我实际上并没有真正使用命名元组来返回东西。所以建议实际上只是要小心,并阅读他说的这句话:“我的关键点是,在你的代码中优先考虑可读性和人体工程学而不是简洁性。这意味着避免使用命名元组,除非你在扩展或调整现有的API,而命名元组比已经使用的普通元组更好。”

所以如果你在做这个,我想我做过,如果你的返回值之前是元组,它已经是一个元组很长时间了。有现有的代码在使用它,但我应该把它改成命名元组。添加命名元组允许人们同时使用两者,这在人体工程学上可能更好。但是,警告是,你有很多测试要做,因为你必须测试两种访问方式。

所以要多测试。好的,是的,这是一个很好的建议,不足为奇。

好的,让我们谈谈另一种编程语言,但我认为这是一个有趣的视角。Zig编程语言,你熟悉吗?不,对我来说也很新。

如果你去看一些例子,它看起来有点像Rust,我不确定,但它做很多简单的事情,比如它可以很容易地与C或Windows API交互,诸如此类。但它看起来很简洁。但它是一种低级编程语言。

所有这些分号和花括号在做什么?

可能可以删除,可能并不真正需要。所以这就是Zig的故事。他们最近在AWS上花了相当多的钱。他们决定,不花支持者的钱在AWS上会更好。

例如,他们说Rust基金会报告说,它在2023年在基础设施成本上花费了404,400美元。他们说,我们对Python之类的不太了解,但是运行Python的成本很高,主要是因为很多基础设施成本是捐赠的。他们说,看看这个东西,它正在增长。我们真的不希望这成为我们的问题。他们每月在AWS上花费高达1000美元,这很不合理。

但是什么?

org在那里?一个Python的副本?org。所以这不是一项基本服务,也不是紧急情况。

如果它宕机了,99%的正常运行时间就足够好了。是最后1%的正常运行时间代表了99%的成本,这很有趣。所以他们说,我们有一个36美元的服务器,它有20TB的带宽,大约包含2000美元的带宽,每月36美元。也许有一天我们会疯狂地花费数百或数千美元。但我们不需要做得更多。这就是正确的做法。

那么他们在做什么?相反,他们说,第一,他们正在鼓励并建立一个具有包镜像的系统,对吧?我们记得我们谈到了那个宠物项目,它会基本签署轮子,然后允许它们托管在其他地方,只要签名匹配。

所以他们从一开始就做这种事情。他们就像我们可以以分布式的方式分散它。所以没有一个东西会受到巨大的打击。

如果它在一个地方失败了,相当于pip,因为他们会,让我们尝试一个镜像或类似的东西,你知道的,是的,也许我说他们就像,好吧,每月36美元,除此之外,他们之前在做什么?AWS,这是他们之前在做的,所以,在AWS上,如果他们想推出一个新的网站。部署需要5分钟。在他们的一个小主机上,推出部署通过所有这些东西,只需要几秒钟。太疯狂了。

它完成了工作。是的,是的。基本上,成本开始检查每一秒。无论如何,我认为这是一个关于云成本的大讨论。没有云是一个关于成本的大讨论。

就像黑天鹅一样,如果支持pip等基础设施的人决定停止呢?你如何突然获得每月10万美元?不,这是一件大事,我认为人们会想出办法,但会有很大的中断。

我喜欢,好吧,我们要建立什么?这个宠物项目有自托管的轮子,已经做了一些存款。但无论如何,这对一个正在成长但非常流行的语言来说很有趣。

有趣,酷。我确实同意,所有这些花括号都是因为Corky提到它也与C交互。所以这很有趣。

是的,是的,这更有可能。是的,我想是的,它是一种语言,对吧?好吧,这就是主要主题,额外的部分。

我有一个额外的内容想让大家知道。所以测试Python测试?我有课程,而且进展顺利。

通过人们获得价值,他们也建立了社区,社区也有一个社区。但它曾经在Slack上,但这是那些增长的事情之一。Slack曾经是免费的,现在不是了。所以我们切换到Podia的论坛,这不好玩。Podia提供了一个论坛,因为课程是在Podia上的,但是,我的意思是,在Podia上几个月后,只有大约5条评论,这根本不行。

网络可以。

现在享受吧,所以我们要尝试Discord,所以我想,坚持住,大家。我正在努力让它与众不同,以便每个人都有社区访问权限。我们将访问Discord服务器。我可能不知道我们要做什么。我希望它是可持续的,所以我不能完全免费,但我希望它易于使用,永远准备好使用,所以我想请大家拭目以待,我会在周末之前完成这件事。无论如何,你还有什么额外的内容吗?

是的,我有一些。这很棘手,对吧?你想选择一个人们已经存在的地方,如果他们有一些Slack或Discord之类的,有很多很酷的选择,你甚至可以有一些需求。

所以自托管的。但是,如果这是一个完全不同的应用程序,人们必须记住打开它,这只是另一个标签,实际上是观众,我认为它会改变。所以对于那些喜欢,去,我在这个东西里,现在我只需要打开下一个标签来查看发生了什么。

在这个社区里,是的,我甚至在我提到它的时候,我的女儿在医疗保健行业工作,她甚至不是我最大的女儿,我向她提到它,她说,哦,我可以帮你。我一直都在Discord上,好吧,太好了。

所以这就是我的想法。我有一些额外的内容,一个仍然存在于你的生活之星周围。好吧,它非常好。所以我继续使用它。

但这实际上是第一个行动,我在Work Item播客上与他们谈论了一个多小时关于Python和业务之类的事情,如果他们想的话,可以看看。这很有趣。是的,我感觉到了。

让我知道我是否之前谈论过这个,Brian,我搜索了又搜索,找不到它。但在我的脑海里,我们谈论过,我是否谈论过你可以订阅,就像RSS一样,来获取?我不知道。

我不这么认为,因为我在我的笔记里没有找到。但无论如何,如果你去任何发布页面,然后在末尾输入“.atom”,你得到的是一个公共的Atom提要。

所以去你的项目,点击发布,然后在末尾加上“.atom”,然后把它放到你的RSS阅读器中。所以如果你喜欢,“嘿,我感兴趣的东西有新版本发布了”,这很酷。然后让我确保我复习一下。

Jamie Thomson说,pytest-bdd(行为驱动开发)有新版本发布了,不仅仅是新版本,而是8.0.0,这是一个大版本,对吧?它最有趣的事情可能是数据表。你见过这些数据表吗?我没有。

它有点像参数化查询,但它也像一个Markdown表格,给定以下用户存在,并且新闻有管道标题、管道名称、管道Twitter,然后值就很好看。啊,对。所以无论如何,如果人们喜欢他们的BDD,他们可以查看pytest-bdd。

那很好。另外,上周我重写了所有代码。我做了一些终端CLI魔法,大约有一万行Python代码不涉及BlinkSpace。

我的意思是,涉及到一行顶级的Python和Python,少一点,但不是很多。我用Corky写的,它是一个类似于Flask的Sink,这太棒了。所以看到它运行效率更高,速度更快,比以前更好,并且在两天内完全重写了一万行代码。

相当大的工作量。你最后很累,让我告诉你什么很酷。结果非常好。我实际上是在两个阶段完成的。一次重写只是为了把它从Pyramid转换为Flask。然后第二次重写,将它从Sink转换为几乎所有代码中的每个输入的Sink,所有这些都是。

数据库查询等等。所以它影响了所有东西吗?

或者主要的影响是什么?它没有影响的某些部分,但是任何需要数据库访问的部分呢?然后在Web框架中,当你编写Web应用程序时,你总是处理框架API的细微方面。所以,我需要获取当前请求的URL,看看我是否应该进行重定向。

好吧,在Pyramid中获取URL的方式与在Flask中完全不同。所以任何接触核心库的东西,如果你想足够多地使用它,那么登录的人,你知道,这也是一个cookie,对吧?令人惊讶的是,它有连锁反应,Flask在某些方面有点笨拙,因为有一个本地请求对象,你可以直接访问它,这很酷,但由于某种原因,调用开始在这里,结束在那里。

也许有一个线程或某种延迟,导致它断开连接,它不会向你抱怨它不知道请求是什么,即使你有一个对象,有很多奇怪的变化。所以是的,但无论如何,这很有趣。我打算写一篇关于这个的文章,但我先把它说出来,进展顺利。

咱们要不要?要不要讲个笑话?一个笑话。这个很棒。

我们讲过简短的笑话,也讲过冗长的笑话,对吧?这可能是最好的长篇笑话。所以,你必须坚持听我一会儿。但是看看这个。

这是新闻,头条新闻:JavaScript 开发人员对一个框架的承诺创下了三周的记录,新闻配图是一群开发者在阴暗角落学习的云图。但是让我读一下,总统没事。看我加利福尼亚州硅谷,在一个史无前例的一致性展示中,让科技界震惊不已,28 岁的 Logo 开发人员 Alex Chen 据报道坚持使用同一个 JavaScript 框架 Astoria 三周。

Chen 在当地死亡圈中被称为“脑力耐力狂”,因为他能够以惊人的速度采用和放弃 JS 框架,自 8 月 1 日以来一直使用 Split 而不间断,打破了他之前使用 UJS 创下的四天记录。

“我不知道我怎么了,”Chen 说,他明显被他自己的稳定性吓坏了。“我有一天早上醒来,只是觉得不想切换到 Angular 或 React,或者其他在面试中提到的新框架。”

这个消息给 JavaScript 社区带来了冲击波。框架制造商据报道正处于危机模式,一家大型科技公司的一位匿名消息人士表示:“如果开发人员不再坚持使用一个框架,我们该如何证明我们的工作价值?”Chen 的同事们表达了各种各样的担忧,资深开发人员 Lisa Patel 指出:“我担心 Alex。昨天我发现他在读文档,而不是立即用一个新的框架重写我们的整个代码库。这根本不像他。”

这件史无前例的事件并非没有挑战。Chen 经历了戒断症状,包括无法控制地想创建新的 IIFE 包,以及持续的瘙痒。尽管情况艰难,但他仍然决心坚持下去。“我一天一天地过,”他说,手指抽搐着,抵抗着尝试 Hype.PX 创建下一个应用程序的冲动。“但我听说有解决方案。”

“啊,新的框架只下载了 50 次。也许我会看看,你知道的,只是为了了解一下情况。对吧?这很酷。”

“嗯,是的,我明白了。”

“我欣赏 Python 的稳定性。我们有很多……我的意思是,这是一个笑话。但它也确实说明了这个领域有很多变化。”

“是的,我的意思是,这里有多少人想过……我应该坚持……”

“使用 Python 还是转向 AG?是的,我的意思是……”

“Zig 的变化少得多。我的意思是,我不认为 Tracor……我认为 Dig……但只是……是的,确实。”

“好吧,如果你想确保你一直坚持到最后,请查看评论区。”

“是的,所以人们只是按字母顺序更换框架。”

“啊,什么都不用改变,这很好。好吧,总是很愉快。感谢你们的收听。谢谢。”