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

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




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

Search: