6 ms·

I've watched the ecosystem from the pre-1.0 days and it is still steadily evolving. New packages are being developed (and abandoned) every day. Some of them are

by tcdent 13y ago

I've watched the ecosystem from the pre-1.0 days and it is still steadily evolving. New packages are being developed (and abandoned) every day. Some of them are very mature, others are just starting, and many are just plain bad. Implementations that stand out, like south, may get incorporated. Especially when they're valuable to the core of Django; all may not agree, but migrations (and class based views) should have been in there from the start. Others depend on your needs. Don't force me into using TinyMCE as a rich text editor, I'll regretfully make that decision myself. I want to choose the best available package for my CDN host. I'm switching thumbnail processing engines because mine hasn't been updated in over two years. Importing all of my models into the shell is best left as an explicit modification for those that want it. If it was a good idea, why wouldn't Django do it by default? Reasons to use Django over other, lighter frameworks: * The ORM * Forms – The ORM * contrib.admin * Authentication * Extendable command line interface

nostrademons 13y ago
It's interesting, I've used Django for several apps (GFiber, various search quality prototypes) that don't at all fit the "database-backed webapp" paradigm. Obviously, the ORM, Form libraries, admin, or authentication libraries didn't factor into that decision at all. What did were: * A standardized, battle-tested system for organizing your code. * Lightweight view definitions. Views are functions from Request to Response in Django, which makes them very easy to define. Django, Flask, and Pyramid all get this right; Python, web.py, and webapp2 get it wrong. Also, Request/Response objects are very sanely designed. * Very full-featured templates & helper functions. If you're going to run into a problem, chances are that Django has already solved it. Lighter-weight microframeworks like Flask don't have this property. * The ability to swap out components you don't need, and to bring in other components as necessary. For example, none of the Django apps I've used since joining Google have used an RDBMS - they all use RPCs as the backend. Oftentimes they need to run proprietary Google code in a controller. This is all not a problem - it's just code, passed between functions as necessary. (Granted, many of them use the Django-nonrel fork.)
- irahul 13y ago
  > Views are functions from Request to Response in Django, The thing that irritates me about django is request is passed as an argument, and if you need if further down the chain, you have to pass it around. I want the request object to be available throughout the request cycle without it being explicitly passed. I like the flask model of importing request when you need it. In Django, I can have a middleware to handle it for me: from threading import local _locals = local() class ThreadLocalMiddleware(object): def process_request(self, request): _locals.request = request @classmethod def request(cls): return _locals.request @classmethod def locals(cls): return _locals But then there are edge cases. What if the threads are being reused? What about greenlets? I am thinking of taking out the flask/werkzeug implementation of locals and LocalManager > Very full-featured templates & helper functions. Django templates are nice; Jinja2 is nicer:-) > Lighter-weight microframeworks like Flask don't have this property. I think it's not just about Flask being light weight. It's more a function of Django existing for longer and being more popular. Granted that Django itself includes lot of batteries which Flask doesn't, but the "somebody has already solved it" is mostly either an extension, or a forum/stackoverflow solution.
  - nostrademons 13y ago
    That's one of the things about Django that I really like and one of the things about Flask that really scares me. I'm writing a retrospective now about things I've learned in almost 5 years of working on Google Search, and the entry I just finished was "In almost every case where we allowed non-local effects, it has bitten us. Badly." The cost is in understandability, and is usually not apparent when the choice to make it a global is made. But 2 years later, things inevitably grind to a halt because bugs are being shipped and nobody has a handle on the code any more. I've cursed out having to explicitly pass arguments around many, many times before (not just with Google work; when I was doing Haskell stuff I used to curse how inconvenient it was that I needed to explicitly pass around stuff, and often wrote a state monad to hide it from myself). But I've found that over time, those apps never hit the brick wall where I'm like "I cannot deal with this anymore"; they remain maintainable, if ugly, indefinitely.

by tcdent 13y ago

nostrademons 13y ago

It's interesting, I've used Django for several apps (GFiber, various search quality prototypes) that don't at all fit the "database-backed webapp" paradigm. Obviously, the ORM, Form libraries, admin, or authentication libraries didn't factor into that decision at all. What did were: * A standardized, battle-tested system for organizing your code. * Lightweight view definitions. Views are functions from Request to Response in Django, which makes them very easy to define. Django, Flask, and Pyramid all get this right; Python, web.py, and webapp2 get it wrong. Also, Request/Response objects are very sanely designed. * Very full-featured templates & helper functions. If you're going to run into a problem, chances are that Django has already solved it. Lighter-weight microframeworks like Flask don't have this property. * The ability to swap out components you don't need, and to bring in other components as necessary. For example, none of the Django apps I've used since joining Google have used an RDBMS - they all use RPCs as the backend. Oftentimes they need to run proprietary Google code in a controller. This is all not a problem - it's just code, passed between functions as necessary. (Granted, many of them use the Django-nonrel fork.)

irahul 13y ago
> Views are functions from Request to Response in Django, The thing that irritates me about django is request is passed as an argument, and if you need if further down the chain, you have to pass it around. I want the request object to be available throughout the request cycle without it being explicitly passed. I like the flask model of importing request when you need it. In Django, I can have a middleware to handle it for me: from threading import local _locals = local() class ThreadLocalMiddleware(object): def process_request(self, request): _locals.request = request @classmethod def request(cls): return _locals.request @classmethod def locals(cls): return _locals But then there are edge cases. What if the threads are being reused? What about greenlets? I am thinking of taking out the flask/werkzeug implementation of locals and LocalManager > Very full-featured templates & helper functions. Django templates are nice; Jinja2 is nicer:-) > Lighter-weight microframeworks like Flask don't have this property. I think it's not just about Flask being light weight. It's more a function of Django existing for longer and being more popular. Granted that Django itself includes lot of batteries which Flask doesn't, but the "somebody has already solved it" is mostly either an extension, or a forum/stackoverflow solution.
- nostrademons 13y ago
  That's one of the things about Django that I really like and one of the things about Flask that really scares me. I'm writing a retrospective now about things I've learned in almost 5 years of working on Google Search, and the entry I just finished was "In almost every case where we allowed non-local effects, it has bitten us. Badly." The cost is in understandability, and is usually not apparent when the choice to make it a global is made. But 2 years later, things inevitably grind to a halt because bugs are being shipped and nobody has a handle on the code any more. I've cursed out having to explicitly pass arguments around many, many times before (not just with Google work; when I was doing Haskell stuff I used to curse how inconvenient it was that I needed to explicitly pass around stuff, and often wrote a state monad to hide it from myself). But I've found that over time, those apps never hit the brick wall where I'm like "I cannot deal with this anymore"; they remain maintainable, if ugly, indefinitely.