librelist archives

Re: [flask] Flask, becoming big, urls

From:

Armin Ronacher

Date:

2010-05-15 @ 14:43

Hi,

On 2010-05-15 1:20 PM, Thadeus Burgess wrote:
> Where does that number come from?
 From the 0.1 one-file "limitation".  A module with more than 4KLOC is 
something I stop calling maintainable.  With 0.2, that limitation no 
longer exists in that form.

> I somehow think you are limiting your framework when it can be so much
> more. Flask is looking to be way much more suiting to large scale
> websites for one reason, it gets out of your way and lets you do what
> YOU want in a pythonic way.
If people start building larger applications I am happy to adapt the 
framework as necessary.  So far I have not heard of any larger 
applications with Flask (well, it's probably also to new for that) so 
most of the becoming-big section is speculation from experience I had 
with similar systems in the past.

> The one limitation that I see is a proper urls.py. We can always drop
> to the werkzeug layer and replace app.url_map with a custom one using
> the werkzeug classes, in fact this might be the best solution,
> documentation regarding this note be made in flask in the becoming-big
> section.
Standard reply to things like that: do some experimentation and if you 
are successful, share with the community.  The snippets archive might be 
the perfect place for documenting alternative ways to declare URLs.  If 
it turns out to be useful I might move that into the core documentation 
or even adapt Flask.

> I would like to see more information on why Thread Locals in the
> becoming-big section, how to fix this.
Why thread locals: because they are simple and allow some interesting 
patterns.  This is similar to garbage collection: it allows a wider 
range of algorithms at cost of runtime performance.  Thread locals (or 
context locals in Flask) allow things like per-request database 
connections be available from anywhere with nearly no extra code needed 
and make such things a breeze, at the cost of having code that might be 
harder to debug, optimize and test.

I do not have a solution for that yet, except for passing an object with 
the state around.  This is like the request object in django, and even 
django falls back to thread locals for certain things such as database 
connections and internationalization.  Getting rid of thread locals and 
keeping a simple API is the holy grail of Python web development.


Regards,
Armin

1) Thats what I wanted to hear :)
2) I am seriously considering flask for a large application, at this
point I am just dipping my feet in the water, and will begin some
prototyping soon.
3) That prototyping will include using a urls.py-ish system, at which
point I will post a snippet.
4) Thank you for the description, from the concept of a web
application, context thread locals seem quite appropriate.

--
Thadeus





On Sat, May 15, 2010 at 9:43 AM, Armin Ronacher
<armin.ronacher@active-4.com> wrote:
> arder to debug, optimize and te