Hi, I'm curious as to what this means: *"*Yes it is usually not such a bright idea to use thread locals. They cause troubles for servers that are not based on the concept of threads and make large applications harder to maintain. However Flask is just not designed for large applications or asynchronous servers. Flask wants to make it quick and easy to write a traditional web application." (from: http://flask.pocoo.org/docs/design/) Where would this cause problems (in a large application, for example)?
Hi,
On 10/28/10 10:07 AM, Hasan Ammar wrote:
> Where would this cause problems (in a large application, for example)?
A thread local is a variable like "request" in Flask that is available
as a global variable but dispatches dynamically to a thread bound
information. This means that when you have more than one request at the
same time the request object will dynamically point to the correct
thread instead without you having to do extra work.
Would this cause problems in a large application? Generally thread
locals are often frowned upon but but Flask provides some helpers to
simplify the work with them. Since Python 2.5 we have access to the
with statement which makes this even easier in combination with helpers
like test_request_context().
I think the documentation outlines advantages and disadvantages more
than once :)
You are always trading stuff in frameworks. Werkzeug as a low level
layer is the most flexible but a lot harder to use than Flask, Flask has
thread locals which saves you a lot of typing and provides you with
tools to implement your own thread bound information, Django usually
goes the explicit approach which is a bit more too type and hides thread
locals (which it needs in a couple of places too) at a location
somewhere in the center of the framework. In case you would need to
roll your own thread local thing in Django.
Regards,
Armin
Thanks for the detailed explanation. Makes sense. Would it be bad practice to, lets say set request.user (or g.user), and then access it directly from a model's save method? It would help make the code cleaner, but I'd like to get input on whether this is a good idea? On Thu, Oct 28, 2010 at 1:42 PM, Armin Ronacher <armin.ronacher@active-4.com > wrote: > Hi, > > On 10/28/10 10:07 AM, Hasan Ammar wrote: > > Where would this cause problems (in a large application, for example)? > A thread local is a variable like "request" in Flask that is available > as a global variable but dispatches dynamically to a thread bound > information. This means that when you have more than one request at the > same time the request object will dynamically point to the correct > thread instead without you having to do extra work. > > Would this cause problems in a large application? Generally thread > locals are often frowned upon but but Flask provides some helpers to > simplify the work with them. Since Python 2.5 we have access to the > with statement which makes this even easier in combination with helpers > like test_request_context(). > > I think the documentation outlines advantages and disadvantages more > than once :) > > You are always trading stuff in frameworks. Werkzeug as a low level > layer is the most flexible but a lot harder to use than Flask, Flask has > thread locals which saves you a lot of typing and provides you with > tools to implement your own thread bound information, Django usually > goes the explicit approach which is a bit more too type and hides thread > locals (which it needs in a couple of places too) at a location > somewhere in the center of the framework. In case you would need to > roll your own thread local thing in Django. > > > Regards, > Armin >
I'd avoid it for no other reason than separation of concerns and ease of testing. For example, if you wanted to use the method in the shell or command line script, how is the user assigned to the g object ? It also makes unit tests clear. On 30 October 2010 08:32, Hasan Ammar <ammarh@gmail.com> wrote: > Thanks for the detailed explanation. Makes sense. > > Would it be bad practice to, lets say set request.user (or g.user), and then > access it directly from a model's save method? It would help make the code > cleaner, but I'd like to get input on whether this is a good idea? > > On Thu, Oct 28, 2010 at 1:42 PM, Armin Ronacher > <armin.ronacher@active-4.com> wrote: >> >> Hi, >> >> On 10/28/10 10:07 AM, Hasan Ammar wrote: >> > Where would this cause problems (in a large application, for example)? >> A thread local is a variable like "request" in Flask that is available >> as a global variable but dispatches dynamically to a thread bound >> information. This means that when you have more than one request at the >> same time the request object will dynamically point to the correct >> thread instead without you having to do extra work. >> >> Would this cause problems in a large application? Generally thread >> locals are often frowned upon but but Flask provides some helpers to >> simplify the work with them. Since Python 2.5 we have access to the >> with statement which makes this even easier in combination with helpers >> like test_request_context(). >> >> I think the documentation outlines advantages and disadvantages more >> than once :) >> >> You are always trading stuff in frameworks. Werkzeug as a low level >> layer is the most flexible but a lot harder to use than Flask, Flask has >> thread locals which saves you a lot of typing and provides you with >> tools to implement your own thread bound information, Django usually >> goes the explicit approach which is a bit more too type and hides thread >> locals (which it needs in a couple of places too) at a location >> somewhere in the center of the framework. In case you would need to >> roll your own thread local thing in Django. >> >> >> Regards, >> Armin > >
Also: the documentation mentions it: Just store on this whatever you want. For example a database connection or the user that is currently logged in. I'm just trying to understand any potential pitfalls of doing this. On Sat, Oct 30, 2010 at 12:32 PM, Hasan Ammar <ammarh@gmail.com> wrote: > Thanks for the detailed explanation. Makes sense. > > Would it be bad practice to, lets say set request.user (or g.user), and > then access it directly from a model's save method? It would help make the > code cleaner, but I'd like to get input on whether this is a good idea? > > > On Thu, Oct 28, 2010 at 1:42 PM, Armin Ronacher < > armin.ronacher@active-4.com> wrote: > >> Hi, >> >> On 10/28/10 10:07 AM, Hasan Ammar wrote: >> > Where would this cause problems (in a large application, for example)? >> A thread local is a variable like "request" in Flask that is available >> as a global variable but dispatches dynamically to a thread bound >> information. This means that when you have more than one request at the >> same time the request object will dynamically point to the correct >> thread instead without you having to do extra work. >> >> Would this cause problems in a large application? Generally thread >> locals are often frowned upon but but Flask provides some helpers to >> simplify the work with them. Since Python 2.5 we have access to the >> with statement which makes this even easier in combination with helpers >> like test_request_context(). >> >> I think the documentation outlines advantages and disadvantages more >> than once :) >> >> You are always trading stuff in frameworks. Werkzeug as a low level >> layer is the most flexible but a lot harder to use than Flask, Flask has >> thread locals which saves you a lot of typing and provides you with >> tools to implement your own thread bound information, Django usually >> goes the explicit approach which is a bit more too type and hides thread >> locals (which it needs in a couple of places too) at a location >> somewhere in the center of the framework. In case you would need to >> roll your own thread local thing in Django. >> >> >> Regards, >> Armin >> > >
> A thread local is a variable like "request" in Flask that is available > as a global variable but dispatches dynamically to a thread bound > information. This means that when you have more than one request at the > same time the request object will dynamically point to the correct > thread instead without you having to do extra work. > > Would this cause problems in a large application? Generally thread > locals are often frowned upon but but Flask provides some helpers to > simplify the work with them. Since Python 2.5 we have access to the > with statement which makes this even easier in combination with helpers > like test_request_context(). <remove> > > I think the documentation outlines advantages and disadvantages more > than once :) > </remove> > You are always trading stuff in frameworks. Werkzeug as a low level > layer is the most flexible but a lot harder to use than Flask, Flask has > thread locals which saves you a lot of typing and provides you with > tools to implement your own thread bound information, Django usually > goes the explicit approach which is a bit more too type and hides thread > locals (which it needs in a couple of places too) at a location > somewhere in the center of the framework. In case you would need to > roll your own thread local thing in Django. This is pretty complete. It would have eliminated my question about that issue, certainly. ;)
The problem is with the advice "don't use Flask for large applications", which may put some people off. The problem is most projects don't start as large applications, they grow into them. Nobody wants to use a framework that's going to have to be abandoned once it gets to be a certain size (depending on your definition of "large"). Do you think the advice still holds ? As you point out, Django uses thread locals, albeit buried in the framework (such as the db connection). Pylons uses them. If it's OK to use them in large applications in Flask, with caveats about good design (e.g. don't drop the "request" object into the middle of your model code) then perhaps this sentence should be removed or amended ? On 28 October 2010 09:42, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > On 10/28/10 10:07 AM, Hasan Ammar wrote: >> Where would this cause problems (in a large application, for example)? > A thread local is a variable like "request" in Flask that is available > as a global variable but dispatches dynamically to a thread bound > information. This means that when you have more than one request at the > same time the request object will dynamically point to the correct > thread instead without you having to do extra work. > > Would this cause problems in a large application? Generally thread > locals are often frowned upon but but Flask provides some helpers to > simplify the work with them. Since Python 2.5 we have access to the > with statement which makes this even easier in combination with helpers > like test_request_context(). > > I think the documentation outlines advantages and disadvantages more > than once :) > > You are always trading stuff in frameworks. Werkzeug as a low level > layer is the most flexible but a lot harder to use than Flask, Flask has > thread locals which saves you a lot of typing and provides you with > tools to implement your own thread bound information, Django usually > goes the explicit approach which is a bit more too type and hides thread > locals (which it needs in a couple of places too) at a location > somewhere in the center of the framework. In case you would need to > roll your own thread local thing in Django. > > > Regards, > Armin >
> Nobody wants to use a framework that's going to have to be abandoned > once it gets to be a certain size (depending on your definition of > "large"). Exactly true. I had similar concerns about that point as well. The implication is that something drastic will need to be done at some point past 'large', meaning it would be the worst time to have to subclass or redesign the guts of the application. The ones that get big usually start as "proof of concept", then "lets run it for a while" and then, "can you add X and Y and Z?" At this point, replying "I need to redesign the app" is usually received poorly...
Hi,
On 10/28/10 3:05 PM, kevin beckford wrote:
> Exactly true. I had similar concerns about that point as well.
That's the problem of a honest documentation. A similar disclaimer
should really be part of the documentation of other projects as well :)
I rephrased that more than once in the past already, so please feel free
to propose better wording :)
Regards,
Armin
On 28 October 2010 14:21, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > On 10/28/10 3:05 PM, kevin beckford wrote: >> Exactly true. I had similar concerns about that point as well. > That's the problem of a honest documentation. A similar disclaimer > should really be part of the documentation of other projects as well :) > Agreed. You're too honest to be any good at marketing :-) > I rephrased that more than once in the past already, so please feel free > to propose better wording :) I'm not sure. There are three (mis)conceptions at work here: 1. Flask is a micro(read:toy) framework, and therefore not suitable for large(read: serious) applications. 2. It uses thread locals, which are dangerous, especially for large applications. 3. If you use Flask for a large project it will blow up and you'll have to replace it with something more stable. The problem is not thread locals as such - Pylons has thread locals and manages fine, as long as you are careful - but that there is no large, serious Flask deployment in the wild yet. We just don't know how Flask will scale either in the development or performance/memory sense - we can't point to a high-traffic site right now and say "it works for them!". However, reading the docs gives the impression that Flask is somehow unsuitable by design for large applications, which means that people are less likely to use it in such projects, which means that we can't know for sure - chicken and egg. It might instead read something like this: "Does Flask scale ? Flask is a new framework, and has not been deployed on any large-scale projects yet. The underlying libraries (Werkzeug, Jinja) are fast and stable and there is no reason to believe that Flask will be the bottleneck in your application. Scalability problems are most often I/O related - such as your database - and Flask will not prevent you from shooting yourself in the foot. However, there are a number of good practices you can undertake to ensure that you don't have Flask-related issues when your application gets bigger, such as using modules, taking care with thread locals etc. (see section on "Becoming big")." Of course once we get a few nice case studies we can change this text, but it's honest while at the same time providing some useful advice.
On 28 October 2010 14:21, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > On 10/28/10 3:05 PM, kevin beckford wrote: >> Exactly true. I had similar concerns about that point as well. > That's the problem of a honest documentation. A similar disclaimer > should really be part of the documentation of other projects as well :) > Agreed. You're too honest to be any good at marketing :-) > I rephrased that more than once in the past already, so please feel free > to propose better wording :) I'm not sure. There are three (mis)conceptions at work here: 1. Flask is a micro(read:toy) framework, and therefore not suitable for large(read: serious) applications. 2. It uses thread locals, which are dangerous, especially for large applications. 3. If you use Flask for a large project it will blow up and you'll have to replace it with something more stable. The problem is not thread locals as such - Pylons has thread locals and manages fine, as long as you are careful - but that there is no large, serious Flask deployment in the wild yet. We just don't know how Flask will scale either in the development or performance/memory sense - we can't point to a high-traffic site right now and say "it works for them!". However, reading the docs gives the impression that Flask is somehow unsuitable by design for large applications, which means that people are less likely to use it in such projects, which means that we can't know for sure - chicken and egg. It might instead read something like this: "Does Flask scale ? Flask is a new framework, and has not been deployed on any large-scale projects yet. The underlying libraries (Werkzeug, Jinja) are fast and stable and there is no reason to believe that Flask will be the bottleneck in your application. Scalability problems are most often I/O related - such as your database - and Flask will not prevent you from shooting yourself in the foot. However, there are a number of good practices you can undertake to ensure that you don't have Flask-related issues when your application gets bigger, such as using modules, taking care with thread locals etc. (see section on "Becoming big")." Of course once we get a few nice case studies we can change this text, but it's honest while at the same time providing some useful advice.
On Thu, Oct 28, 2010 at 4:02 PM, danjac354@gmail.com <danjac354@gmail.com> wrote: > On 28 October 2010 14:21, Armin Ronacher <armin.ronacher@active-4.com> wrote: >> Hi, >> >> On 10/28/10 3:05 PM, kevin beckford wrote: >>> Exactly true. I had similar concerns about that point as well. >> That's the problem of a honest documentation. A similar disclaimer >> should really be part of the documentation of other projects as well :) >> > > Agreed. You're too honest to be any good at marketing :-) > >> I rephrased that more than once in the past already, so please feel free >> to propose better wording :) > > I'm not sure. There are three (mis)conceptions at work here: > > 1. Flask is a micro(read:toy) framework, and therefore not suitable > for large(read: serious) applications. > 2. It uses thread locals, which are dangerous, especially for large > applications. > 3. If you use Flask for a large project it will blow up and you'll > have to replace it with something more stable. > > The problem is not thread locals as such - Pylons has thread locals > and manages fine, as long as you are careful - but that there is no > large, serious Flask deployment in the wild yet. We just don't know > how Flask will scale either in the development or performance/memory > sense - we can't point to a high-traffic site right now and say "it > works for them!". > > However, reading the docs gives the impression that Flask is somehow > unsuitable by design for large applications, which means that people > are less likely to use it in such projects, which means that we can't > know for sure - chicken and egg. > > It might instead read something like this: > > "Does Flask scale ? > > Flask is a new framework, and has not been deployed on any large-scale > projects yet. The underlying libraries (Werkzeug, Jinja) are fast and > stable and there is no reason to believe that Flask will be the > bottleneck in your application. Scalability problems are most often > I/O related - such as your database - and Flask will not prevent you > from shooting yourself in the foot. However, there are a number of > good practices you can undertake to ensure that you don't have > Flask-related issues when your application gets bigger, such as using > modules, taking care with thread locals etc. (see section on "Becoming > big")." > > Of course once we get a few nice case studies we can change this text, > but it's honest while at the same time providing some useful advice. > +1 This one seems a really good rewording. It's clear and honest, but not scaring ;-) Alex
+1 for danjac's rewording Mayowa. On Thu, Oct 28, 2010 at 3:15 PM, Alex <thinkpragmatic@gmail.com> wrote: > On Thu, Oct 28, 2010 at 4:02 PM, danjac354@gmail.com > <danjac354@gmail.com> wrote: > > On 28 October 2010 14:21, Armin Ronacher <armin.ronacher@active-4.com> > wrote: > >> Hi, > >> > >> On 10/28/10 3:05 PM, kevin beckford wrote: > >>> Exactly true. I had similar concerns about that point as well. > >> That's the problem of a honest documentation. A similar disclaimer > >> should really be part of the documentation of other projects as well :) > >> > > > > Agreed. You're too honest to be any good at marketing :-) > > > >> I rephrased that more than once in the past already, so please feel free > >> to propose better wording :) > > > > I'm not sure. There are three (mis)conceptions at work here: > > > > 1. Flask is a micro(read:toy) framework, and therefore not suitable > > for large(read: serious) applications. > > 2. It uses thread locals, which are dangerous, especially for large > > applications. > > 3. If you use Flask for a large project it will blow up and you'll > > have to replace it with something more stable. > > > > The problem is not thread locals as such - Pylons has thread locals > > and manages fine, as long as you are careful - but that there is no > > large, serious Flask deployment in the wild yet. We just don't know > > how Flask will scale either in the development or performance/memory > > sense - we can't point to a high-traffic site right now and say "it > > works for them!". > > > > However, reading the docs gives the impression that Flask is somehow > > unsuitable by design for large applications, which means that people > > are less likely to use it in such projects, which means that we can't > > know for sure - chicken and egg. > > > > It might instead read something like this: > > > > "Does Flask scale ? > > > > Flask is a new framework, and has not been deployed on any large-scale > > projects yet. The underlying libraries (Werkzeug, Jinja) are fast and > > stable and there is no reason to believe that Flask will be the > > bottleneck in your application. Scalability problems are most often > > I/O related - such as your database - and Flask will not prevent you > > from shooting yourself in the foot. However, there are a number of > > good practices you can undertake to ensure that you don't have > > Flask-related issues when your application gets bigger, such as using > > modules, taking care with thread locals etc. (see section on "Becoming > > big")." > > > > Of course once we get a few nice case studies we can change this text, > > but it's honest while at the same time providing some useful advice. > > > > +1 > > This one seems a really good rewording. It's clear and honest, but not > scaring ;-) > > Alex >