前段时间看到 paddleocr 感觉还可以

迟到的支持 不错

@woshicixide #14 +1 非常好奇

做啊，分离是为了提高效率

https://github.com/fy0/slim

已经稳定用了很久。最近会对各种历史遗留问题做一个彻底改动。当前版本主要是反映设计理念

async/await asyncio typehints dataclass f-string

生成 curd 啊，我搞过：
https://github.com/fy0/slim

就是文档写的不好，实践了两三年了，有些 API 的设计存在问题，最近正在重构。

@abersheeran 原来是进垃圾箱了，捂脸。发了申请先睡觉了。

写了一封邮件给你

感觉我们做的工作互补性还挺强的，有没有兴趣后面一块搞点事情（比如共用的基础设施，表单验证、ORM 、权限机制等等）？

其实单从性能优化角度上讲，你还可以上 cython 然后打编译后的 wheel 传上 pypi，不过你用的打包工具是 poetry，好像是不支持二进制 wheel 包。

@abersheeran #2

我觉得 API 应该和数据更近，把 CRUD 的工作自动做掉。建立这个项目的时候，当时已经有 graphql 了，但一直觉得 graphql 思路很正确，但是不接地气，个人 /小团队来说有学习成本，大公司又有自己的一套体系同样用不上。

应该有一种和传统接口形式类似的，易于使用的 API 框架。不过实践中用了几年也发现了挺多问题，所以包括权限、验证、SQLView 我都打算重新设计并重做了。
总之做一个很大的 break change.

架构设计的任务过重，细节的性能优化就只能先放一放了，反正 ASGI 的思必得够快。先把 feature 做好，fastapi 这种缝合怪也做的风生水起不是吗？

原来是 web 框架
我在写的时候也想过 router 怎么弄，比如弄成一个大正则，根据匹配的 group 查 index 就知道是哪一个了。c 写的化简之后的 nfa 应该不慢吧？

但是到了最后就偷懒了，我发现路由地址分两种，一种是确定的地址，占绝大多数。另一种是正则，占少量。那就为绝大多数做优化，由于确定的地址就是个 str，那么做个 dict 一查就行了，代价是 O(1)，剩下正则就遍历。
可能还有必要优化，不过我觉得思考 web 框架解决的问题比 router 更重要，暂时就不管了。

看了 lz 的框架，真是同一个世界同一套技术栈，asgi uvicorn redoc aiofiles click pytest

不同的地方是我对 pydantic 心存疑虑，我觉得报错信息太奇怪了，但是好像目前也没其他选择。

此外我完全舍弃了模板的部分，因为我觉得 0202 年了，大家都前后端分离已经没人用模板了。框架没必要支持这个。

还有就是感觉自己文档写的真心差，比不上 lz 写的（虽然内容也不多）完全没指望有开发者来用一样。

这是我的 web 框架
https://github.com/fy0/slim

router 实现
https://github.com/fy0/slim/blob/master/slim/base/route.py

听着真魔幻，大概这就是 Windows 发行版？

近距离接触大佬，支持一下

资瓷资瓷 硬核讨论好久不见

关注一下 这个确实头大