3 ms·
I'm a big fan of flask, purely because there's no wrangling `request` objects down your stack, and you can just fish it out later when you need it. My main com
by suvelx 9y ago
I'm a big fan of flask, purely because there's no wrangling `request` objects down your stack, and you can just fish it out later when you need it.
My main complaint would be Flask's 'extensions'. I'm really not a fan of the
> app = Flask(__name__)
> db = Database(app)
pattern. it makes getting your db back later a little trickier. It would be nice if the `Flask` instance held it for you, so you could get it back with `flask.current_app` later.
It further doesn't work when the plugin provides a sets of views (i.e. CRUD) e.g.
> app = Flask(__name__)
> crud = CrudPlugin(app)
I've yet to see a case of why this isn't implemented as a blueprint.
- keosak 9y agoExtensions can register themselves with the Flask application object, so you can look there: current_app.extensions['whatever']. However, it is not specified what exactly this dictionary contains, so eg. SQLAlchemy puts a custom State class there. You can still get the extension object out of it, it's just that there is no common convention. http://flask.pocoo.org/docs/0.12/api/#flask.Flask.extensions http://flask.pocoo.org/docs/0.12/api/#flask.Flask.extensions https://github.com/mitsuhiko/flask-sqlalchemy/blob/master/flask_sqlalchemy/__init__.py#L608 https://github.com/mitsuhiko/flask-sqlalchemy/blob/master/fl...