Hacker News new | past | comments | ask | show | jobs | submit login

While flask is a nice framework, it has some problems. I worked with numerous python web frameworks, mainly webapp2 and flask. So some things i don"t like about flask:

Disclaimer: You can architect beautiful apps in apps, its just easy todo it wrong.

GLOBALS: Flask has a lot of globals (from flask import g, request, current_user, etc.) A better web handler function looks like this handle(request) -> response. Any other web framework that I know does it like this. Much better. Flask promotes touching the 'request' object everywhere. Example: https://github.com/lepture/flask-wtf/blob/master/flask_wtf/f.... Flask is not functional, its inherently statefull with globals.

MIDDLEWARE: Flask promotes writing middleware as decorators functions, while it looks nice, it not really useable anywhere else, and its not really a standard. At least you can still use WSGI middleware.

BLUEPRINT are nice, but have issues: When you create a blueprint, for a sub app, you cant set error handlers. They only work on app level. Also (small issue) You cant add blueprint specific middleware.

Better way to create 'sub apps': Use a new WSGI App. Or use a sitemap where you bind functions to paths.

SITEMAP @route has disadvantages For big apps, its nice to have a single routes.py file where you can see all urls the app supports, and which methods to handle those. The @route is nice to use initially, but imho for big apps it becomes messy. Also it promotes circular imports:

  view.py:
  from init import blueprint #circular import!
  blueprint.route('/test/')
  def f(): pass


  init.py:
  blueprint = new Blueprint
  from . import view
  assert view # ensure the handlers are initiallized



Haven't used flask in some time now, but most of your objections are missing the mark.

> GLOBALS: Flask has a lot of globals (from flask import g, request, current_user, etc.) A better web handler function looks like this handle(request) -> response. Any other web framework that I know does it like this.

Flask's request is not global. I have had this discussion with someone else before:

https://news.ycombinator.com/item?id=6662623

FWIW, flask's "from flask import request" never had been a blocker for me, whereas django's injected request variable had made me write middleware to preseve requests as thread locals so that I can access it elsewhere. Werkzeug does the same thing, except it does it more robustly.

> MIDDLEWARE: Flask promotes writing middleware as decorators functions, while it looks nice, it not really useable anywhere else, and its not really a standard. At least you can still use WSGI middleware.

I don't see an issue. If you can solve it using simple python(decorators), solve it using Python.

> BLUEPRINT are nice, but have issues: When you create a blueprint, for a sub app, you cant set error handlers. They only work on app level. Also (small issue) You cant add blueprint specific middleware.

Rather than calling app.before_request, you can call blueprint.before_request and it will work only for that blueprint.

> SITEMAP @route has disadvantages For big apps, its nice to have a single routes.py file where you can see all urls the app supports, and which methods

Then don't use the decorator. Have a routes.py and call app.add_url_rule

I have had a template with all of this from some time back

https://github.com/rahulkmr/flask-bigapp-template


> GLOBALS: .. Flask does not have a lot of globals. You are misunderstanding the g, request current_user object types. They are most certainly not globals, they are session proxy objects. Because we are in python they can be made to look like globals. They are done like this to be convenient. If you use the 'request' one hundred times in a file, some of us don't want to be bothered to put it as a formal parameter to every function.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: