你们对 Python 的 Flask 框架的设计有什么看法吗？
V2EX 上 Pythoner 应该比较多，不知道大家对于这个框架怎么看。
我最近也是花了一点时间学了学，感觉这个框架在设计上有很多不是很优雅很规范的地方。
官方文档条理不是很清晰，先不说翻译质量，就英文文档来说，没有像 CodeIgniter 的文档一样把每一个模块小节涉及到的函数的函数原型贴出来，基本上很多东西得边写边试才知道，如果时间很紧迫可能我并没有那么多时间去一个一个 API 的试，也不会把他文档里面的长篇大论全部看一遍，当然我知道他有 API 文档，但是毕竟 API 只是起一个工具字典的作用，很多概念还是得靠文字解释来理解。还有比如说 WEB 应用最常见的 GET，POST 居然放到很后面才讲，而且一会儿 request.form 一会儿 request.args.get，要么还有直接 app.route 里面取值的，不像别的编程语言一样都是统一的 API 获取。还有作用域，对于很多从 PHP，Java Servlet 等转过来的开发者可能对于为什么 request 需要保证线程安全等的概念不是很了解，而官方文档对于这个问题也是很简单的略过，还有命名用什么 g，current_app，request 等等，命名也不统一一下，像写 PHP 或者 ASP，我知道可以知道其中一个 API 之后后面的举一反三，这个 Flask 在 API 设计上命名风格没有统一让强迫症有点受不了啊。
还有我看的是 http://docs.jinkan.org/docs/flask/ 这个版本的翻译，我没有为开源社区贡献什么，也不好怎么批评，求大家推荐一些更好的翻译版本或者 Flask 相关的学习资料，谢谢了！
你们对 Python 的 Flask 框架的设计有什么看法吗？
Flask的设计哲学很对我胃口。它把“微”这个字做到了骨子里，核心就一个文件，依赖少得可怜。路由、模板、请求上下文这些该有的都有，但绝不替你做决定。想用ORM？自己装SQLAlchemy或Peewee。要表单验证？WTForms等着你。这种“工具箱”式的设计让项目从原型到生产都能保持结构清晰。
最漂亮的是它的装饰器路由和上下文机制。用@app.route定义接口直观得要命，而像g、request这些线程隔离的全局对象，解决了很多Web开发里的状态管理麻烦。它的蓝本系统也够用，能把应用按功能拆成模块。
当然，这种自由度过高的设计是把双刃剑。新手容易把各种代码全堆在一个文件里，搞出意大利面条式的结构。但话说回来，这其实逼着开发者自己思考架构，而不是被框架牵着鼻子走。
总结：Flask是给明白人用的工具。
flask 是我最欣赏的 python web 框架，我觉得它的设计十分简单优雅，尤其你列举的那些不好用的地方，在我看来都是精髓。
可能楼主对优雅和规范的认识和 flask 的设计者们不太一样吧
flask 的设计是我见过的最简洁优雅的，没有之一，按理说其他语言的 web 框架我也接触过一些，java 的 spring,php 的 tp5，感觉都没比 flask 好啊，怎么就不优雅了？
doc 一般只会讲 api 使用吧，你还要别人跟你讲 Request 线程安全
不会直接去查这方便的文档么？ 搜搜 Request Flask 如何保证线程安全就一大堆 LocalProxy 什么的
文档很好用，入门方便
current_app 用于工厂模式下的 app
flask 设计地更精心，要研究一下才能了解。
研究完了就会觉得很多你认为理所当然的地方都是 flask 独特的地方。
再或者，你试试我的框架？（认真脸
对就这个地方很疑惑，还有测试那个章节有点看不懂他的写法，反正理解起来很费劲，也是我没有理解这个框架的精髓。我之前写 php 之类的没有过这种写法，所以现在接触 flask 很多地方都不理解，但是文档也确实很多地方没有讲为什么需要这样写。而且我网上搜索了一大圈，flask 中文方面的资料太少了。 我写 php 的
如果确实有这个问题，要么来个 tip 点明一下，要么就讲完整，而不是好几个地方穿插一点，讲一半还讲的模棱两可（当然也有可能是翻译问题），毕竟设计模式里面也讲究一个单一职责。你看看文档里面讲作用域，那么一次性讲完，别路由里面穿插一点请求，穿插一点作用域，顺便还讲讲全局作用域，请求和路由之间还穿插一下模板引擎，静态文件导入的教程之类的。我认为这个官方文档内容还算可以，但是详略不是很得当而且顺序安插还是有很多问题。
你看看 codeigniter 的文档从头到尾清爽明了，是什么章节专注讲什么内容。关于 session 锁的问题，至少会讲明白 session 为什么需要锁，没有锁会导致什么后果，然后就快速结题。这样无论是对老鸟还是菜鸟都很友好
我觉得不是这样的，doc 本来就是快速的给使用方法。 至于你要每一个 API 都要详细深入， 这个就是马上一本书的体量了。
我觉得好的 API 就是给出使用方案， 然后详细的实现，理念。 给出一个链接进去专门的 url。 这样才能深入浅出。
而且我觉得你对 web 理解真的还不行呢。。你要的一些答案早就有人探讨了很多。
我希望有那种快速入门的文档，既然是一个微型框架，那么也别把入门弄得比一些全栈框架还繁琐。codeignitor 就是一个典型，文档解耦合做的非常好，我需要什么就看什么，而且他的 api 原型写的清晰明了，任何一个有 php 基础和了解 mvc 的人绝对看十几分钟之后就可以开始用它写项目，而 flask 文档就太啰嗦了，没有重点和粗体标识，就像很多中小学教科书一样，我又不敢跳着看，生怕略过什么。
#16 你以前写 Java, 为什么会不熟悉线程安全的问题啊？ Java Servlet 跑起来的时候也是多线程的啊，访问数据库也是靠连接池，和 python 的并发模型应该是完全一样的，应该只有语法糖上的区别吧
首先我觉得题主文档没看对，出名的开源项目还是先把官方的摸熟了再看其他比较好。
如果要说 flask 怎么样，我推荐看看这篇 https://wakatime.com/blog/14-pirates-use-flask-the-navy-uses-django
Pirates use Flask, the Navy uses Django 这个观点是很有兴趣的，当然我觉得海盗思维使用 django 其实更有杀伤力。
大部分观点我认同，特别是性能方面的观点。
用 python 还要来追求性能我一直觉得是在讲笑话，且嗤之以鼻。基于 python 做 web 开发更多的是追求开发效率。
要知道现在一个程序员的工资可够你买很多台机器做性能提升了。
另外现在的机器对 DAU 没过千万的网站，python 也足够了。要说瓶颈，大部分 web 场景其实都是 IO 的瓶颈，和中间件没什么关系。
另外本人支持 django，flask 真的只适合小大小闹，当项目大了，你一样要不得不引入 class view 的概念。
数百个控制器，一样需要把 url 模块化。 看看 flask，blueprint 一引入，整个项目就又丑了。
最后你会发现，这和 django 有什么区别呢？ 微服务吗？基于 django 难道就不能设计微服务了吗？
又一个重复的轮子。
我司現在就在用 flask，可能是我們技術水平的問題，並不覺得在項目體量上去以後 flask 的伸縮性多麼好，再加上各種插件質量參差不齊，實際感覺不如用 django，django 並不重，想要輕量級可以參考 lightweight django 這本書。至於 flask 設計精巧的問題，與 python 其他框架相比，如 pyramid，cherrypy 等，flask 的優勢並不是非常的明顯，至少沒有非常突出的特點。
主要是你都用 blueprint 了，跟 Django 的子应用已经没太大区别了。面对大而全的 Django，也就是风格上面的差异罢了。至于 mongodb 完全跟 django 一切使用，Django 内跟 ORM 非常紧密耦合的地方其实不多，大可以用你自己顺手的库。
如果从其他语言来的刚接触 Flask 是有点困难，上手之后用来写中小型的项目妥妥的。和 Django 没什么可比性，设计目的都不一样。
另外这文档质量不咋地，也很旧，里面还是建议使用 Python2，而官方的文档很久之前就改了建议使用 Python3
http://docs.jinkan.org/docs/flask/advanced_foreword.html#python-3
http://flask.pocoo.org/docs/0.12/python3/#python3-support
