Hi list, I've been using flask for some weeks now and I'm very happy with it, but the documentation states that not big nor complex applications can be built on top of flask [0]. What looks really worrying to me is the following paragraph: "For example, Flask uses thread-local objects internally so that you don’t have to pass objects around from function to function within a request in order to stay threadsafe. While this is a really easy approach and saves you a lot of time, it might also cause some troubles for very large applications because changes on these thread-local objects can happen anywhere in the same thread." This raises some questions: * What is a big/complex/very large application for Flask? * Has anyone had any issues with this? * In case I get to the point of hitting those problems, are there workarounds? * Do you recommend patching the framework or using another? Kind regards, [0] http://flask.pocoo.org/docs/foreword/ -- Alvaro Mouriño http://askani.net/
Hi, On 6/16/11 8:35 PM, Alvaro Mouriño wrote: > be built on top of flask [0]. What looks really worrying to me is the > following paragraph: Flask's documentation is just brutal honest. You would have to add similar things into the documentation of Pyramid or Django as well as both are using thread locals for the one or other thing. We noticed that many people are being slightly confused about that wording, so we're carefully rewriting small parts of that chapter every once in a while. Regards, Armin
> I've been using flask for some weeks now and I'm very happy with it, > but the documentation states that not big nor complex applications can > be built on top of flask [0]. What looks really worrying to me is the > following paragraph: Flask poorly labels itself a "micro framework." My guess is this this label was applied as a django counter-culture statement and way of identifying itself in the django-dominated python framework arena of software. IMO, what Flask really means to say is "Flask is a web development toolkit." There are many ways you can build your application and it's entirely up to you to figure out how to achieve your goal. Flask provides many ways to achieve this as Flask provides tools (all small, pluggable and good at whatever they set out to achieve), but it does not take the "mother knows best, let's install a bazillion-anti-footshooting devices that require more effort to work around than actual benefit" approach. I hope that distinction conceptually helps your understanding of what Flask does and doesn't do (and why it's fantastic vs a burden). -sc -- Sean Chittenden sean@chittenden.org
On Thu, Jun 16, 2011 at 2:55 PM, Sean Chittenden <sean@chittenden.org> wrote: >> I've been using flask for some weeks now and I'm very happy with it, >> but the documentation states that not big nor complex applications can >> be built on top of flask [0]. What looks really worrying to me is the >> following paragraph: > > Flask poorly labels itself a "micro framework." My guess is this this label > was applied as a django counter-culture statement and way of identifying > itself in the django-dominated python framework arena of software. The micro designation here is analogous to that of operating system kernels: monolithic vs micro. A mircrokernel (e.g. MINIX) uses as small of a core as possible [as does the Flask core] while passing off to microkernel servers provide features [as does the Flask extension architecture], whereas a monolithic kernel (e.g. Linux) takes an integrated approach. > IMO, what Flask really means to say is "Flask is a web development toolkit." Werkzeug is the toolkit in the stack. Flask is like a toolkit in that it's a framework by example. You are encouraged to subclass and fork to provide the behaviors you desire. -Ron
On Thu, Jun 16, 2011 at 2:35 PM, Alvaro Mouriño <alvaro@mourino.net> wrote: > "For example, Flask uses thread-local objects internally so that you > don’t have to pass objects around from function to function within a > request in order to stay threadsafe. While this is a really easy > approach and saves you a lot of time, it might also cause some > troubles for very large applications because changes on these > thread-local objects can happen anywhere in the same thread." > > This raises some questions: > * Has anyone had any issues with this? No, because I am very careful about what thread-local objects my applications create. I build applications on Flask which I consider to be large, with no problems whatsoever. -Ron
I have the same fears, Flask is great, fun to use, too easy to learn, have great extensions... but they are too many warnings in the official docs for larger applications... and *what about scalability?* *it is recommended for startups?* There can be many questions because of these warnings... I am searching a python framework for a project with some friends and right now I have a lot of doubts because I want Flask (we are running away from django inflexibility)... But I heard in the Flask IRC about Blueprints for Flask 7.0: *"Flask uses a concept of blueprints for making application components and supporting common patterns within an application or across applications. Blueprints can greatly simplify how large applications work and provide a central means for Flask extensions to register operations on applications."* More info here: [ http://goo.gl/W8Dpj] I guess that Flask team will try to fix these holes, Flask still young, and the community seems to be needing solutions for larger applications, if you ask me, the only think that Flask need to be an excellent framework is an easy approach to build larger applications keeping the core-framework concept. The big question could be... *What about the future of Flask?*
Héllo, 2011/6/16 Andrés Villalobos <andresalvivar@gmail.com> > I have the same fears, Flask is great, fun to use, too easy to learn, have > great extensions... but they are too many warnings in the official docs for > larger applications... somewhat true, but you should have a look at modules : http://flask.pocoo.org/docs/patterns/packages/#working-with-modules I read on irc that the team was working on improved facility for module/submodule/application/whatever-the-name, but I may be wrong > and *what about scalability?* *it is recommended for startups?* This is a broad question, answer : yes/no/maybe :) > There can be many questions because of these warnings... I am searching a > python framework for a project with some friends and right now I have a lot > of doubts because I want Flask (we are running away from django > inflexibility)... > welcome aboard ;) > But I heard in the Flask IRC about Blueprints for Flask 7.0: *"Flask uses > a concept of blueprints for making application components and supporting > common patterns within an application or across applications. Blueprints can > greatly simplify how large applications work and provide a central means for > Flask extensions to register operations on applications."* More info here: > [http://goo.gl/W8Dpj] > interresting link, thanks. Amirouche --- OH « Future is yours »
I remember before that there was a task list for some low-hanging fruit. Can someone forward me the link so that I maybe able to contribute some effort and time to help out? ~Jonathan C. On Thu, Jun 16, 2011 at 1:13 PM, Amirouche Boubekki < amirouche.boubekki@gmail.com> wrote: > Héllo, > > 2011/6/16 Andrés Villalobos <andresalvivar@gmail.com> > >> I have the same fears, Flask is great, fun to use, too easy to learn, have >> great extensions... but they are too many warnings in the official docs for >> larger applications... > > > somewhat true, but you should have a look at modules : > http://flask.pocoo.org/docs/patterns/packages/#working-with-modules > > I read on irc that the team was working on improved facility for > module/submodule/application/whatever-the-name, but I may be wrong > > >> and *what about scalability?* *it is recommended for startups?* > > > This is a broad question, answer : yes/no/maybe :) > > >> There can be many questions because of these warnings... I am searching a >> python framework for a project with some friends and right now I have a lot >> of doubts because I want Flask (we are running away from django >> inflexibility)... >> > > welcome aboard ;) > > >> But I heard in the Flask IRC about Blueprints for Flask 7.0: *"Flask uses >> a concept of blueprints for making application components and supporting >> common patterns within an application or across applications. Blueprints can >> greatly simplify how large applications work and provide a central means for >> Flask extensions to register operations on applications."* More info >> here: [http://goo.gl/W8Dpj] >> > > interresting link, thanks. > > Amirouche > > --- > > OH « Future is yours » >
On Thu, Jun 16, 2011 at 4:43 PM, Jonathan Chen <tamasiaina@gmail.com> wrote: > I remember before that there was a task list for some low-hanging fruit. Can > someone forward me the link so that I maybe able to contribute some effort > and time to help out? Issue tracker is here: https://github.com/mitsuhiko/flask/issues -Ron > > ~Jonathan C. > > > On Thu, Jun 16, 2011 at 1:13 PM, Amirouche Boubekki > <amirouche.boubekki@gmail.com> wrote: >> >> Héllo, >> >> 2011/6/16 Andrés Villalobos <andresalvivar@gmail.com> >>> >>> I have the same fears, Flask is great, fun to use, too easy to learn, >>> have great extensions... but they are too many warnings in the official docs >>> for larger applications... >> >> somewhat true, but you should have a look at modules >> : http://flask.pocoo.org/docs/patterns/packages/#working-with-modules >> I read on irc that the team was working on improved facility for >> module/submodule/application/whatever-the-name, but I may be wrong >> >>> >>> and what about scalability? it is recommended for startups? >> >> This is a broad question, answer : yes/no/maybe :) >> >>> >>> There can be many questions because of these warnings... I am searching a >>> python framework for a project with some friends and right now I have a lot >>> of doubts because I want Flask (we are running away from django >>> inflexibility)... >> >> welcome aboard ;) >> >>> >>> But I heard in the Flask IRC about Blueprints for Flask 7.0: "Flask uses >>> a concept of blueprints for making application components and supporting >>> common patterns within an application or across applications. Blueprints can >>> greatly simplify how large applications work and provide a central means for >>> Flask extensions to register operations on applications." More info here: >>> [http://goo.gl/W8Dpj] >> >> interresting link, thanks. >> >> Amirouche >> --- >> OH « Future is yours » >
Hi,
On 6/16/11 9:59 PM, Andrés Villalobos wrote:
> The big question could be... *What about the future of Flask?*
It's bright :)
Regards,
Armin
2011/6/16 Armin Ronacher <armin.ronacher@active-4.com>: > Hi, > > On 6/16/11 9:59 PM, Andrés Villalobos wrote: >> The big question could be... *What about the future of Flask?* > It's bright :) Thanks everyone for all the comments. As many of you said, the docs are a bit frightening and make flask look as a site mock up tool, but from your comments I see - correct me if I'm wrong - that it suffers the same flaws as any full stack framework. I don't think that those paragraphs should disappear from the docs, on the contrary, it should be extended with a careful explanation, some examples and a list of good practices to follow. Even if those good practices are not limited to flask, would be nice to have it there. What can I do to help? Should I create a ticket for this? -- Alvaro Mouriño http://askani.net/
Hi, On 6/17/11 3:00 AM, Alvaro Mouriño wrote: > As many of you said, the docs are a bit frightening and make flask > look as a site mock up tool, but from your comments I see - correct me > if I'm wrong - that it suffers the same flaws as any full stack > framework. To give a little bit of context for why the documentation is written the way it is: Flask started out as an Aprils fool's joke mocking bad design decisions in certain other frameworks and the lack of acknowledgment that certain things are not optimal. Now that joke had enough impact that I actually decided to turn that around and make something that is a best practice framework instead. (Which is why the tagline has "good intentions" in there). However starting out there we were very careful not to slide into the same direction as I was originally criticizing. :) > I don't think that those paragraphs should disappear from the docs, on > the contrary, it should be extended with a careful explanation, some > examples and a list of good practices to follow. Even if those good > practices are not limited to flask, would be nice to have it there. In general documentation is still lacking and we would love to update it. If you have some good suggestions, try yourself on rewording it and open a pull request on github or give us some good suggestions here. Regards, Armin