3 ms·

I mostly agree with the author of the article: ever try to modify the User object to accept an email instead of username for login purposes? It's a complete hac

I mostly agree with the author of the article: ever try to modify the User object to accept an email instead of username for login purposes? It's a complete hack. The thing is, it didn't need to be a hack, but some of the core components are really tightly coupled together when they don't need to be, so it ends up being a hack. This tends to happen a lot when you 'go outside the box' of Django's codebase. For example, everyone says you can 'use SQLAlchemy' in Django. On paper this is true. But then you lose the admin, the user auth system, the messages system, model forms, and all of the other batteries that make Django useful. That said, the alternatives to Django are so incredibly lacking that (for the moment), I'd rather stick with Django than roll my own everything else. Pylons and Turbogears are an ugly mish-mash of third party libraries that don't work well together. In some cases there are good third party libraries (SQLAlchemy is indeed quite an amazing piece of software), but many other pieces are lacking: - Authentication/authorization libraries are terrible. (You want to bury that in the middleware layer and use query string parameters to indicate login failure? What?) - Nothing out there is as good as Django's model forms. - There is no equivalent to sorl-thumbnail, for basic image processing. - The boatload of third party Django apps. Yes, most of these are poorly written and not modular enough either but there are some really useful ones out there like django-pagination and django-compress. Django is far from perfect but unfortunately, taken as a whole, it's still better than the current alternatives.

henriklied 16y ago
> For example, everyone says you can 'use SQLAlchemy' in Django. On paper this is true. But then you lose the admin, the user auth system, the messages system, model forms, and all of the other batteries that make Django useful. Using SQLAlchemy doesn't change any of that. For pre-built components, like auth and admin, just go with the flow. You're free to use SQLAlchemy side-by-side with Django's ORM.
- stevenwei 16y ago
  Really? What happens when you want to start customizing the User model, perhaps linking it to a UserProfile. Perhaps you want to have many Users belong to the same Account? Do you create duplicate representations of your models in SQLAlchemy and Django? What happens when you need to start migrating your database schemas? Forgive my lack of imagination, but I can't think of any way of doing what you suggest without it coming across like a horrible hack.
zeemonkee 16y ago
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.

henriklied 16y ago

> For example, everyone says you can 'use SQLAlchemy' in Django. On paper this is true. But then you lose the admin, the user auth system, the messages system, model forms, and all of the other batteries that make Django useful. Using SQLAlchemy doesn't change any of that. For pre-built components, like auth and admin, just go with the flow. You're free to use SQLAlchemy side-by-side with Django's ORM.

stevenwei 16y ago
Really? What happens when you want to start customizing the User model, perhaps linking it to a UserProfile. Perhaps you want to have many Users belong to the same Account? Do you create duplicate representations of your models in SQLAlchemy and Django? What happens when you need to start migrating your database schemas? Forgive my lack of imagination, but I can't think of any way of doing what you suggest without it coming across like a horrible hack.

zeemonkee 16y ago

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.