 |
yxtV2EX 第 2419 号会员，加入于 2010-10-16 20:51:02 +08:00今日活跃度排名 12683 |
yxt 最近回复了
360 天前 回复了 lijianmin321 创建的主题 › 分享创造 › V 站老哥太热情了， Airy 永久会员加送 9000，凑到 1 万 |
支持一下
2023-05-11 11:01:02 +08:00 回复了 ryanz91 创建的主题 › 问与答 › 昨天尝试了一下 poetry，发现 pycharm 里面直接安装依赖会报错 |
2022-10-15 16:43:38 +08:00 回复了 cocong 创建的主题 › 程序员 › 就差最后一步， Windows 就能基本满足我的需求了。 |
2022-10-06 16:08:04 +08:00 回复了 Livid 创建的主题 › 分享发现 › 一个很漂亮的 { 个人简历, 团队主页, 职业社交 } 网站 |
跟一个 :) https://read.cv/join/yuuuxt
2022-05-14 20:38:56 +08:00 回复了 imdgr886 创建的主题 › 程序员 › URLCron 更新了，同时提供 10 个高级版兑换码 |
24 已用, 谢谢
2022-01-21 14:15:59 +08:00 回复了 kuanos 创建的主题 › 问与答 › 迫于需要在 n 多个 word 文档里找到关键信息，求方法 |
2021-05-25 17:00:32 +08:00 回复了 tolecen 创建的主题 › 分享创造 › 之前做的一个离线制作证件照的 App，新上了 Android 版本，送几个永久会员给大家 |
VEX483600243 已用, 谢谢
2021-05-14 10:04:45 +08:00 回复了 greyli 创建的主题 › Python › Flask 2.0 版本发布 |
@abersheeran
这 虽然暴露了依赖的细节 但我大部分时间还是对着 fastapi 的文档写呀 我直接面对的并不是 starlette 以及我虽然没使用异步，一整个项目还是做下来过的
大意如此，我不会因为依赖关系而区别对待
这 虽然暴露了依赖的细节 但我大部分时间还是对着 fastapi 的文档写呀 我直接面对的并不是 starlette 以及我虽然没使用异步，一整个项目还是做下来过的
大意如此，我不会因为依赖关系而区别对待
2021-05-13 22:36:41 +08:00 回复了 greyli 创建的主题 › Python › Flask 2.0 版本发布 |
@abersheeran
@frostming
@greyli
首先向各位开源大佬问个好 :) 技术上向各位学习, 这儿仅就 @greyli 的文章的观点讨论一二.
关于项目愿景, 定位和技术定位, 严格上说的确 FastAPI 和 Flask 不完全对应, 理解各位这个思考问题的角度.
我的角度更偏用户:
- 用户用的是谁的 API, 就是在用哪个"框架", FastAPI 在 starlette 上包了一层, 用户没有直接用 starlette, 就说明这层包装有意义 (或, 最终发现无意义而弃之), 没必要去强调依赖关系, 技术上的核心和用户的感知不一定是统一的 (此处 @abersheeran );
- 用户基于流行程度 /成熟程度的比较是很自然的逻辑: 先筛选流行 /成熟的, 再对照看有没有满足自身需求. 首先判断两者是否等价, 是否直接可比? 不太可能吧.
- opinionated 和通用性是中性的, 无视趋势的通用性和过于小众的偏见都会损失用户. FastAPI 的流行说明它的确解决了一些用户痛点, 代表了相当一部分用户的实际需求.
- 假定 FastAPI 的方向是"正确"的, 如果 Flask 选择目前的定位, 那这样的比较和用户的流失是会长期存在的, 直到 FastAPI 更为流行, 两方的用户能够明确地"各取所需"为止. (此处 @frostming )
再提两句 @greyli 的原文, 我的核心意见, 还是"从用户角度, Flask 和 FastAPI 并不是不可比的":
- 首先说文中的靶子, 该文描述了 FastAPI 在编写 API 场景相对 Flask 的写法优势, 逻辑我认为是自洽的. 文中写: "你确定你用了四年的是 Flask 而不是 Flash ？" 难道, 在使用 Flask 编写 API 时, 并不是这样的吗?
- @greyli 认为两者虽然都很流行, 但是定位不同不能直接比较. 理论上这是对的, 但我认为是没什么意义的, 流行程度本就是非常重要的筛选器;
- 框架仅用于编写 API, 应该可以代表大部分使用者的场景(欢迎指正). FastAPI 的流行也印证了这一点;
- 文中提到的 FastAPI 的问题的确存在, 但次要. 文中提的文档中的"「大胆」的措辞和承诺以及不厌其烦的特性介绍", 这个不厌其烦, 怕是把各种推介者的搬运算上了吧? 一个精心设计的 readme 并不是负分项.
以及对 APIFlask 的推介:
- 非常赞同作者对自己心血的推介, 只是窃以为在此文中显得不太合适;
- 窃以为 marshmallow 不如 pydantic, 待 @greyli 了解评价一下.
最后是 @greyli 的一些答复:
> 我在那篇文章里没找到我表达过「 FastAPI 写法简洁」、「简洁的写法并不是 FastAPI 所独有的」这些观点
"FastAPI 写法简洁"是靶子文所表达的, "简洁的写法并不是 FastAPI 所独有的" 是我提议的如果想树立靶子, 则可以考虑论述的一个方向;
> Benchmarks
不反对技术层面对比的一致性要求.
@frostming
@greyli
首先向各位开源大佬问个好 :) 技术上向各位学习, 这儿仅就 @greyli 的文章的观点讨论一二.
关于项目愿景, 定位和技术定位, 严格上说的确 FastAPI 和 Flask 不完全对应, 理解各位这个思考问题的角度.
我的角度更偏用户:
- 用户用的是谁的 API, 就是在用哪个"框架", FastAPI 在 starlette 上包了一层, 用户没有直接用 starlette, 就说明这层包装有意义 (或, 最终发现无意义而弃之), 没必要去强调依赖关系, 技术上的核心和用户的感知不一定是统一的 (此处 @abersheeran );
- 用户基于流行程度 /成熟程度的比较是很自然的逻辑: 先筛选流行 /成熟的, 再对照看有没有满足自身需求. 首先判断两者是否等价, 是否直接可比? 不太可能吧.
- opinionated 和通用性是中性的, 无视趋势的通用性和过于小众的偏见都会损失用户. FastAPI 的流行说明它的确解决了一些用户痛点, 代表了相当一部分用户的实际需求.
- 假定 FastAPI 的方向是"正确"的, 如果 Flask 选择目前的定位, 那这样的比较和用户的流失是会长期存在的, 直到 FastAPI 更为流行, 两方的用户能够明确地"各取所需"为止. (此处 @frostming )
再提两句 @greyli 的原文, 我的核心意见, 还是"从用户角度, Flask 和 FastAPI 并不是不可比的":
- 首先说文中的靶子, 该文描述了 FastAPI 在编写 API 场景相对 Flask 的写法优势, 逻辑我认为是自洽的. 文中写: "你确定你用了四年的是 Flask 而不是 Flash ？" 难道, 在使用 Flask 编写 API 时, 并不是这样的吗?
- @greyli 认为两者虽然都很流行, 但是定位不同不能直接比较. 理论上这是对的, 但我认为是没什么意义的, 流行程度本就是非常重要的筛选器;
- 框架仅用于编写 API, 应该可以代表大部分使用者的场景(欢迎指正). FastAPI 的流行也印证了这一点;
- 文中提到的 FastAPI 的问题的确存在, 但次要. 文中提的文档中的"「大胆」的措辞和承诺以及不厌其烦的特性介绍", 这个不厌其烦, 怕是把各种推介者的搬运算上了吧? 一个精心设计的 readme 并不是负分项.
以及对 APIFlask 的推介:
- 非常赞同作者对自己心血的推介, 只是窃以为在此文中显得不太合适;
- 窃以为 marshmallow 不如 pydantic, 待 @greyli 了解评价一下.
最后是 @greyli 的一些答复:
> 我在那篇文章里没找到我表达过「 FastAPI 写法简洁」、「简洁的写法并不是 FastAPI 所独有的」这些观点
"FastAPI 写法简洁"是靶子文所表达的, "简洁的写法并不是 FastAPI 所独有的" 是我提议的如果想树立靶子, 则可以考虑论述的一个方向;
> Benchmarks
不反对技术层面对比的一致性要求.
Select Language