[Flask] Subclassing flask.Flask?

David Lord davidism at gmail.com
Thu Apr 6 16:55:52 EDT 2017

A class is an instance factory, so you're not really doing anything except
moving the pattern around by doing that refactor. The point of the proxy
globals is that the don't have to be passed around to each function that
needs them. Either way it's a style choice, doesn't really matter.

On Apr 6, 2017 13:43, "Gergely Polonkai" <gergely at polonkai.eu> wrote:

> Hello,
> I don't see anything wrong with that; in fact, Python is a language where
> you can do the same thing in many different ways.
> I don't really see the advantages of application factories and module
> globals; if you don't have a Flask instance, you can't use them anyway. If
> you have a Flask instance, why would you use them instead of class
> properties?
> Right now I'm trying to transition a relatively big Flask app from app
> factory to Flask subclass. There are a lot of measurements to do, but so
> far it looks cleaner (to me).
> Best,
> Gergely
> On Fri, Mar 31, 2017, 14:49 Skip Montanaro <skip.montanaro at gmail.com>
> wrote:
>> I'm getting to the point with a smallish Flask application that I
>> really don't want a bunch of module-level global variables sitting
>> around. My initial inclination would be to subclass flask.Flask, but
>> picking through the documentation and the prominent examples
>> (minitwit, etc), I didn't see any examples of this. This leads me to
>> believe that maybe that's not the correct route for corralling my
>> data.
>> I'll give you one small example. My database is actually constructed
>> from a set of files which are updated outside of my control. I'd like
>> to run a separate thread to incrementally update the relevant bits of
>> my database as individual files change. The straightforward (to me)
>> way to do this is to have a separate thread which keeps things
>> up-to-date. As I'm currently using sqlite3, that suggests I need to
>> lock access. Storing the necessary threading.{RLock,Lock} object at
>> the module level seems iffy. I'd prefer to keep it as an instance
>> attribute. Once I've got a subclass, why not put all the
>> implementation in instance methods with the necessary @app.route
>> decorators?
>> So, am I off-base in thinking I should subclass the Flask class? Is
>> there a more prevalent pattern?
>> Thx,
>> Skip Montanaro
>> _______________________________________________
>> Flask mailing list
>> Flask at python.org
>> https://mail.python.org/mailman/listinfo/flask
> _______________________________________________
> Flask mailing list
> Flask at python.org
> https://mail.python.org/mailman/listinfo/flask
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/flask/attachments/20170406/e3949b8e/attachment.html>

More information about the Flask mailing list