虽然听起来有点离题，但我想说抛开学历或是找工作，可以多尝试看看自己喜欢哪个技术方向，这样研究起来就不会那么痛苦。甚至是看看技术之外对哪些东西感兴趣，毕竟大多数人在大学之前是家长和老师的木偶，走出校园又秒变工具人，也就大学这段时间可以舒展自己的本性。升本是有必要，但是升本后的两年倒可以尝试多做点课程之外的事情（也就是不要做大家都在做的事情），这样或许可以避免在求职的时候被使用学历这一个维度评价。比如：

- 做出作品（从自己的兴趣出发，从小的作品开始）
- 学好英语（到可以听说的程度）
- 学习国外的计算机公开课
- 参与开源项目

以及不要被学历局限住，你是一个独立的人，学校只不过是一个空壳。社会有它的评价体系，但你应该有自己一套。

---

有时间计划写一些关于学历和找工作相关的东西，大概会是下面这个演讲的扩展：

https://www.bilibili.com/video/av67369394

另外附上我之前找工作的经历供参考：

https://greyli.com/job-hunting/

P.S. 我 17 年专科毕业，本来打算拿到自考毕业证再去找工作，结果自考到现在都还没有考完……

@RRRoger 啊，不好意思，我没导入试过……日历文件里的时间晚了 8 个小时 https://github.com/PyConChina/PyConChina2021/issues/26 。 欢迎明天来参加，上午九点半开始。

@rogwan API 框架和手动集成各种库相比，主要的功能是自动生成 OpenAPI spec 和 API 文档，再就是简化了一些验证请求数据生成错误响应的代码。

> 至于 marshmallow，flask + marshmallow 组合的易用性远低于 fastapi

@Kilerd 方便展开说说易用性差在哪里吗？其实 APIFlask 就是 Flask+marshmallow 的组合，而 FastAPI 则是 Starlette+Pydantic 的组合。

@Kilerd 还是有不少文章的，你没搜到可能是因为拼写错了：是 Pydantic，不是 Pydynamic 。

另外还有两个相关的扩展（后者添加了生成 OpenAPI spec 的支持）：

- https://github.com/bauerji/flask_pydantic
- https://github.com/turner-townsend/flask-pydantic-spec

@Kilerd

> 大多数人在接受过 fastapi 那基于 pydynamic 的类型检查后再回去使用原始的 flask 处理模式。

既然 FastAPI 可以集成 Pydantic，那 Flask 未必就要用原始的处理模式呀。完全可以自己选择搭配不同的数据序列化库，比如 Pydantic 或是 marshmallow 。

> 至于基于 flask 的 api 框架，没看到一个能打的。

请问你对 APIFlask https://apiflask.com 有什么想法和建议吗？我希望它可以成为能打的那个 :P

@loading

> 104 份提交就做分析了？

因为没人填。大部分提交都是在问卷发布后宣传的那一阵，后续两个月就基本没有多少了。不过 104 份已经能够反映出很多问题了，重合率比较高的几个事情（ API 支持、异步、扩展维护）也都是目前 Flask 社区的关注点。

@akring 幸存者偏差是指哪里？无业率 4.8% 那里是开玩笑的……

@fishily1993 很高兴能帮到你 :)

@rationa1cuzz 不是烧瓶啊

如果用一个没有盖子的 drinking horn 图片，那么就会更容易区分了。虽然大部分人也许没见过这种动物角做的杯子，但是不会误认为是辣椒（或是肛塞……）。

@jdkl 可以挑一个简单的章节试试看。

@summerwar 谢谢提议，目前只是临时翻译，具体在 https://github.com/greyli/flask-docs-zh/discussions/37 有讨论和投票。

@firejoke 哈哈，握爪~

@hello2060 是的。

@yxt

> 5. FastAPI 的推介者没有义务一定要从 FastAPI 是基于 Starlette 和 pydantic 的一个衍生框架这个角度来介绍, 开发者也没有义务一定要把这句话放在第一句, 技术背景放在 requirements 里很正常, 又不是刻意隐藏;

同样，我那篇文章里也没有说过推介者和开发者有义务怎么样、技术背景放在 requirements 里不正常在刻意隐藏。我只是在论述引起错误对比的三个原因。建议反驳观点时原文引用。


> 6. PR 里大量的文档翻译工作作为用户是喜闻乐见的(虽然我是看英文的), 虽然从开发角度看的确比较停滞.

用户要看的是翻译结果，而不是「 PR 里大量的文档翻译工作」，把翻译放到单独的仓库或是用翻译平台协作会是对用户和开发者都更友好的方式。

@yxt

> 4. 再说这个靶子, 原文写了 FastAPI 写法简洁的优势, 如果 APIFlask 可以做到类似的事情, 为何不正好 show 一下以论述 "简洁的写法并不是 FastAPI 所独有的"? 我感觉 marshmallow 并没有 pydantic 好用.

我在那篇文章里没找到我表达过「 FastAPI 写法简洁」、「简洁的写法并不是 FastAPI 所独有的」这些观点。建议后续讨论原文引用。

介绍 APIFlask 并不是那篇文章的主题，如果读者感兴趣的话，自然会点进对应的链接去了解 APIFlask 。我提及 APIFlask 是因为它是基于 Flask 的扩展和框架里唯一和 FastAPI 对等的比较对象（欢迎不同观点），而不是为了推广它而强行加进去。不过仅仅这样都让你认为我的主题是「"既然看到了 FastAPI, 也来看看 APIFlask 这个新项目"」，那我要是像你说的「正好 show 一下」，估计你就要认为这是 100% APIFlask 软文了吧……

至于 Marshmallow 和 Pydantic 哪个好用，见仁见智，我对 Pydantic 不够熟悉，没法提供更多观点。

我也一直想深入对比一下用 FastAPI 和 APIFlask 的各种写法的不同，但是一来没有时间，二来对 FastAPI 还不够熟悉，所以目前的对比仅限于一些基本特征，详见 https://apiflask.com/comparison/#apiflask-vs-fastapi 。

附注那篇文章（《请不要把 Flask 和 FastAPI 放到一起比较》）的链接供后来者参考：

https://greyli.com/flask-fastapi/

@yxt 关于观点 1 、2 、3，也就是能不能比较的问题，我的观点都在文章里表达的差不多了，再重复也没有什么意义，@frostming 也补充了一些解释。我完全接受你不认同我的观点，你可以写一篇《我认为 Flask 和 FastAPI 可以放到一起比较》，我会把文章附到结尾供读者参考。

唯一想要补充的是，如果你读过 FastAPI 的文档，那么在 Benchmarks 这一章（不太清楚为什么放到这里）有一段已经说明了关于「比较」的问题：

> If you are comparing FastAPI, compare it against a web application framework (or set of tools) that provides data validation, serialization and documentation, like Flask-apispec, NestJS, Molten, etc. Frameworks with integrated automatic data validation, serialization and documentation.

https://fastapi.tiangolo.com/benchmarks/

简单翻译如下：如果你在比较 FastAPI，把它和提供数据验证、序列化和文档的 Web 框架（或工具集合）进行比较，比如 Flask-apispec 、NestJS 、Molten 等等；把它和集成了自动化数据验证、序列化和文档的框架进行比较。

我想这是不是可以理解为 FastAPI 作者也认为 FastAPI 不能和 Flask 一起比较呢？这或许能够稍微改变你的看法。

观点 4 、5 、6 晚点回复，去吃早饭了。

@olddog5172 似乎是你所在地区的网络问题？