It's a typical scenario really. On the surface it gives you a great framework for creating a website that works in a certain way but if you deviate from that you tend to find yourself in trouble.
In our case it was mostly the admin section that created the issues. I'm sure that if you know the framework well enough there are ways around the inflexibility but the fact of the matter is, the Django admin is heavily based on configuration. Where you have configuration you have limitations.
Things may have changed (it was about a year ago when I last worked with it) but at the time I struggled with simple things like; customising the auth system, easy debugging / error handling, clean outgoing email switching between dev / live, the templating system, etc. I seem to recall spending most of my time ripping code from the core framework into my views.py and tweaking it so I could get the behaviour the client was asking for.
As I say, it's been a while since I worked with it and I'm sure people have solutions to the issues I encountered but if you're planning on going off piste at all it's probably not for you.
The admin is amazingly malleable. Almost everything can be overridden and replaced. There's plenty of nice debugging/logging solutions (Werkzeug+Django Extensions being my favourite). Email switching between dev/producution is trivial (unless I'm misunderstanding you).
There ARE some clunky parts to customizing auth - mainly around extending the User model - but it's not that terrible.
Regarding the email stuff, my criteria for a framework is that I'd like it to send real emails on live and fake ones on dev. That is, email everything to me on dev along with a little header showing who the email was going to etc. Invaluable for testing.
settings.py is a mess. Even Simon's written a post bashing it (http://simonwillison.net/2009/may/19/djng/). I cringe a little starting up a project and having to dive into the settings.py file.
In some ways, Django tries to be flexible, but it's clumsy. For example, you can have your templates in your app directories. So, you have /path/to/project/posts/templates and /path/to/project/people/templates. However, you can't just put your templates in there because Django doesn't namespace them. Like, if I do {% extends "people/base.html" %} it will look in both those template directories for a people folder. It won't be like, "oh, I should look in /path/to/project/people/templates/base.html". I have to put the template in /path/to/project/people/templates/people/base.html. That's clumsy.
urls.py is another flexible/clumsy thing (IMO). Django wants me to write a regexp for the simple cases. It's kludgy to do r'^people/(?P<id>\d+)/?$' just to have a URL with an ID in it. And other frameworks have been able to offer the power of regexps for the case where you want them while making the common cases a lot easier.
Django caches certain things and if you try to change it at runtime, well, it doesn't change.
Django's reusable apps aren't that reusable. They were a lot more reusable than Rails' apps, but the Rails team has worked on that a lot - especially with 3.1 and how each app can have its own assets (images/css/js) all namespaced and neat and tidy. There isn't as much utility there as advertised. Like, if I want to use a Django "reusable" app, I often have to manage images/css/js manually, figure out where to put them, etc. This is one of those interesting ones. Like, I have my /var/projects/cool_project directory, but if I put the reusable app under that directory, then I need to have both /var/projects/ and /var/projects/cool_project in my pythonpath which feels wrong. It also feels wrong to put it directly in the projects dir since it isn't a project on its own.
Django doesn't really have init hooks. Like, you can stick random code into the models.py files for installed apps and they'll be loaded when the app is initialized and so you could set things then and, well, it's python so the __init__.py files should get loaded. However, no one seems to talk about it. Granted, almost no one in the Rails community talks about init files, but it seems a tad more common. I mean, it's Python and so clearly one can write Python, but while Django is extensively documented for what I'll call "blessed features", I wish there was a little more talk about making alterations at startup.
I never really warmed to Django's forms. They're fine, but they don't feel good. I hesitate to say this one because my argument is "they feel clumsy" and I'm sure many agree with that and many disagree with that.
Here's one that recently got resolved: nearly everyone had written their own wrapper around render_to_response so that they wouldn't have to do render_to_response('tpl_name.html', {}, context_instance=RequestContext(request)). In Django 1.3 they added the awesome render(request, 'tpl_name.html', {}). It's not even a big thing, but it felt so clumsy before to have to set a kwarg with such a long object name.
Rails has really settled on that Gemfile and you can use pip/virtualenv and requirements.txt, but it doesn't seem to be as much of a thing. Like, it isn't always about what can be done as much as what is done sometimes. Plus, the Gemfile makes the app require the libraries. I'd have to also add them to settings.py or somewhere else. And I'd potentially have to add it to INSTALLED_APPS and TEMPLATE_CONTEXT_PROCESSORS and MIDDLEWARE_CLASSES since you can't just install an app and have it work in those places without naming it specifically in settings.py
Here's a counter example. Let's say that no one agreed on what the main content block would be called in base templates - or that base templates would be "base.html". It would make templates from reusable apps useless since they might be {% extends "home.dj" %} or {% extends "layout.tpl" %}. They could have {% block main_content %}. It does matter what people do in practice sometimes.
Really? No migrations? I have to resort to a third-party project? I should have the SQL sent out to my terminal, go into my database, figure out the deltas and apply the SQL? While I'm on database stuff, would it kill Django to specify InnoDB and UTF-8 for MySQL when creating tables? I get it, most of them use PostgreSQL and I like PostgreSQL, but I'm not always using it and it's a sensible default to go with InnoDB and UTF-8 unless told otherwise - and loads of people don't know or forget to set that as the MySQL default.
Now, I could also write one of these about Rails if I wanted to. Anything that has worth will have plenty of warts. It's the nature of creation. I wouldn't write this unless I cared a lot about Django. I enjoy using it. But there will always be things I'm not fond of in it (or in Rails, or anything else - even if I created it).
For myself, the thing I don't like most about Django is the "well, we didn't think of it/need it and there's a third party project so, well, I guess we're not going to go there" situation that I feel sometimes. Now, I wanted to stress that this is a feeling more than something objectively accurate. Migrations are one of those things. User authentication, an admin section, a basic CMS, sitemaps, lorem ipsum, textile, markdown, restructured text, a list of US states, a comments framework, etc. all have made their way into Django. Now, those are some useful things. I don't need all of them on every project, but batteries are nice (even if they're those D batteries and I don't have a device that uses them). However, migrations are a tad fundamental. Likewise, it was many years before the messaging framework worked for non-logged-in users (like Rails' flash). Yes, many people had put out a little package that one could use, but (without something awesome like a Gemfile) it takes more than a little setup. I mean, it isn't arduous, but it isn't free. And the point of frameworks is what they do for you for free. Heck, someone posted on django-developers a couple months back about prepared statements (http://groups.google.com/group/django-developers/browse_thre...). If you've seen Aaron Patterson's presentation on Rails and prepared statements (http://www.youtube.com/watch?v=kWOAHIpmLAI), you can see the benefits of them. Prepared statements are in Rails 3.1. The message on django-developers seemed to get a very luke-warm response because Django has kinda decided that they don't want to deal with connection pooling - after all, there are already third party libraries for that (even if they aren't so integrated and require more user setup and work). So, the fact that Django doesn't want to deal with connection pooling means that the great speedup that could be had from prepared statements won't happen. And yes, I could put the patches on myself and when Django makes new releases re-apply the patches (and figure out if anything broke) and deal with potential edge cases where the patch wasn't right, etc. and set up a connection pooler and get my prepared statements and the speedup that comes with them. But that's kinda kludgy and feels restrictive. And for a framework that likes PostgreSQL, they're missing out on a large speed bump by not using the query planner effectively.
Again, I could make a list about Rails or any sufficiently large project (it's hard to criticize web.py or something since the retort would simply be "it isn't meant to do that"). This doesn't mean that Django is bad or that I dislike Django - it's quite the opposite. Personally, I don't care about things I don't like. People are free to do as they like. However, when there's something that I'm 95% "wow, that's awesome", the 5% that I'm like, "omg, this is crap" bothers me. I'm not sure if you were looking for a response to "what's so clumsy, restrictive, etc. that one shuldn't use it". If that was your question, well, I think people should use Django (and Rails). But just because something is good, doesn't mean that it doesn't have clumsy pieces that will annoy you.
My pet hate is contrib.auth - the models used feel seriously out of date and the whole get_profile() thing feels inefficient and hacky. Almost every client I work with does not want usernames but email login these days and I have to use the same damn workarounds each time. I get the feeling there were some bad decisions made early on in the project - maybe to work around the lack of model inheritance back then - and they've stuck, but still somehow need to be defended.
And yes, for crying out loud, South needs to be part of Django itself. This "we shouldn't have opinions" is a crock. Everyone who needs migrations uses South. When we don't have South but we have a highly opinionated - and practically useless - comments app, that argument doesn't hold water.
Like yourself, though, most of the time Django does what I need, I can make it work, and love 90% of it - the ORM, forms, middleware etc "fit my brain" and work nicely. But the framework still needs a lot of work and some serious wart removal.
"I often have to manage images/css/js manually, figure out where to put them, etc"
This has (yay!) been solved in 1.3 with the inclusion of the staticfiles app. I now just put my app-specific static stuff in static/ and then run manage.py collectstatic and all is well in the world :)
I'd completely missed it. Thanks!
It's a trivial thing to add, but its lack really hurts sometimes.
That one I completely disagree with, especially considering the idea of reusable applications.
While the repetition of 'people' does feel redundant at first glance, it means a second application can have its own `people/base.html` template which will be used instead of the one originally provided by `people`, and without needing any magical manipulation of paths/namespaces in the template loader. The path within the templates folder is completely independent from the path outside of it. And I think that's a fine behavior for the app_directories and the eggs loaders.
Furthermore, note that you could write your own template loader based on these which will do the namespace munging for you. How is that "Django tries to be flexible, but it's clumsy"?
FYI, I think the South authors are the ones preventing South being part of Django, not the Django maintainers.
I don't think either "side" (if there is such a thing as "sides" here -- South's lead developer has a commit bit on Django) wants to just transplant South into Django directly. The plan, which got hashed out secretly behind closed doors in a shadowy back room (on our public mailing list), is to work the low-level support for migration-ish stuff -- APIs for DB manipulation, etc. -- into Django, but not officially "bless" any particular high-level implementation.