4 ms·

I agree with your conclusions on Django auth (and I really hate the UserProfile hack) - and once you start swapping out the template engine and ORM you lose muc

I agree with your conclusions on Django auth (and I really hate the UserProfile hack) - and once you start swapping out the template engine and ORM you lose much of the usefulness of Django (as well as most of the 3rd party apps). If you take away admin, auth etc I really don't see much that's compelling about Django. However you are also correct about Pylons - I would like to recommend it but the documentation is terrible and has its own share of hacks (the "c" global, @validate decorator etc). Rolling your own isn't that painful though - you might want to look at Werkzeug. Coupled with SQLAlchemy and Jinja2 you have a really nice DIY framework for very little effort, that grows with your project. I'd also like to mention WTForms which uses a similar pattern to Django forms and is very easy to use and extend. The Flask microframework, while just a few weeks old, is built on top of this toolkit and looks very promising, especially for beginners to Python web development or smaller projects.

stevenwei 16y ago
Yes if I rolled my own it would almost certainly be on top of Werkzeug/SQLAlchemy/Jinja2. The history of Flask is amusing but I'm not particularly interested in another microframework - 80% of web app development is doing the same boring shit over and over again (user logins, permissions, registration, form processing, image uploads, password resets, REST apis, etc). Microframeworks punt on all of that stuff and expect you to reinvent the wheels there. We don't need more microframeworks in the Python world, what I really want to see is a full stack alternative to Django that took care of all of the boring stuff so web app developers could focus on the 20% of work that makes their app really unique.
- zeemonkee 16y ago
  The problem with something like login/registration is that on the one hand it's a repetitive task, on the other it's something that ends up being highly customised for each application. My experience with Django is that you generally start with the generic login and registration views, but quickly end up ditching them when you need something just a bit different. I'm not sure what would be a better solution, and I'm not sure there is one. I've yet to see a solution that is neither a) too complex (AuthKit) nor too simplistic (Django). Form processing and REST are a bit more low level and should be achievable by a modestly-sized framework or library.
  - stevenwei 16y ago
    I agree that the end implementation of a User login and registration system will be highly customized for each application. However, I think there is a TON of reusable code out there that is shared across apps: simple things like setting properly salted and hashed passwords, providing a password reset mechanism, and a base user object with permissions and groups. Django gets a lot of this stuff right, what they get wrong is the complete lack of customizability which means you need to throw everything away once you go outside the box. A few simple base classes that could be extended and overridden with custom fields would solve that problem entirely - the reason Django doesn't provide this (IIRC) is because the built in auth system was written before their ORM properly supported inheritance.
    - zeemonkee 16y ago
      Class-based generic views would go a long way as well; Django's generic views are pretty useless in their current form.
- didip 16y ago
  I remembered a framework that stitch exactly those (Werkzeug/SQLAlchemy/Jinja2). It's called http://glashammer.org/ http://glashammer.org/

stevenwei 16y ago

Yes if I rolled my own it would almost certainly be on top of Werkzeug/SQLAlchemy/Jinja2. The history of Flask is amusing but I'm not particularly interested in another microframework - 80% of web app development is doing the same boring shit over and over again (user logins, permissions, registration, form processing, image uploads, password resets, REST apis, etc). Microframeworks punt on all of that stuff and expect you to reinvent the wheels there. We don't need more microframeworks in the Python world, what I really want to see is a full stack alternative to Django that took care of all of the boring stuff so web app developers could focus on the 20% of work that makes their app really unique.

zeemonkee 16y ago
The problem with something like login/registration is that on the one hand it's a repetitive task, on the other it's something that ends up being highly customised for each application. My experience with Django is that you generally start with the generic login and registration views, but quickly end up ditching them when you need something just a bit different. I'm not sure what would be a better solution, and I'm not sure there is one. I've yet to see a solution that is neither a) too complex (AuthKit) nor too simplistic (Django). Form processing and REST are a bit more low level and should be achievable by a modestly-sized framework or library.
- stevenwei 16y ago
  I agree that the end implementation of a User login and registration system will be highly customized for each application. However, I think there is a TON of reusable code out there that is shared across apps: simple things like setting properly salted and hashed passwords, providing a password reset mechanism, and a base user object with permissions and groups. Django gets a lot of this stuff right, what they get wrong is the complete lack of customizability which means you need to throw everything away once you go outside the box. A few simple base classes that could be extended and overridden with custom fields would solve that problem entirely - the reason Django doesn't provide this (IIRC) is because the built in auth system was written before their ORM properly supported inheritance.
  - zeemonkee 16y ago
    Class-based generic views would go a long way as well; Django's generic views are pretty useless in their current form.
didip 16y ago
I remembered a framework that stitch exactly those (Werkzeug/SQLAlchemy/Jinja2). It's called http://glashammer.org/ http://glashammer.org/