Django does not accomodate all. The architecture is a bit more adaptive than rails, given the way the desginers allowed for plug-in "apps" inside the system. Aside from that, its the same stuff basically.
Huh, i'd say Django is LESS flexible than Rails, as it comes with it's own ideas about end-user UI (Rails does not).
Rails doens't have "plug-in apps" in the same way as Django, because Rails doesn't have "apps" at all, apps are what you build with Rails, not part of Rails.
(And Rails does sort of support plug-in apps in the form of 'engine gems' -- but there are no conventions for how different engines interact with each other, because Rails doesn't establish conventions for end-user UI, it consistently does not go to as high a level of abstraction as Django. This has plusses and minuses of course).
Really, like what? I don't consider the admin to be end-user and even if it is, its highly customizable.
Django is really more modular and customizable than people give it credit for. Perhaps, because it works one way "out of the box" and you have to look deeper and learn it to have it work some other way.
> Django is LESS flexible than Rails, as it comes with it's own ideas about end-user UI
what?
Contrary to Rails, Django never forced front-end solutions upon the user, and every suggestion on the dev list to do so is dismissed, which I'm in particular very happy with. The exception is admin, being a full-featured out of the box solution, but even there are some occasional talks about decoupling the orm/forms/admin and provide generic APIs.
Don't see how Django apps are really any different from Ruby Gems/Plugins.
Furthermore, ActiveRecord is much less tied into Rails core than the Django ORM is to Django.[1]
[1] - Yes, you technically can not use the ORM, but then you don't get the Django Admin, which, frankly, is the only thing Django has over many other Python web frameworks.
Sure, in terms of features either available in core or through third party gems/apps, both Rails and Django are pretty much on parity. You won't find anything worthwhile in the Rails world to tout over Django, since there probably exists an equivalent (or if not a port is soon to appear). Likewise, this works the other way around.
What makes me personally prefer Django is the approach the developers take, which when compared to Rails is more conservative. If something is to change in Django, the old way generally gets marked as deprecated a few version prior, and changes are introduced to have limited impact. I mean, even when Django changed the base directory structure of a new project they made sure that old code with the old directory structure would still work in most cases.
For the new url template syntax in 1.5 (they changed it to fix an inconsistency with other tags, as well as to support a new use case to allow variables as an argument), a from-future fix was introduced early on (in 1.3 even!) so that people with slow moving projects could safely ignore the problem until they could get around to fixing it, while people with fast moving projects can adopt the new "correct" behavior early.
Not to say incremental upgrades are always painless, but the pain is limited and well documented. Things that can be introduced on the users schedule (like the new url template syntax), are.
In some ways, that could end up being a disservice. Django can't move as fast or change as much as Rails can. But really, that's what you signed up for. If you bought into Rails and now you're mad that the floor is moving, you really should've considered that in the first place. Likewise, if you bought into Django and you wonder why it doesn't have ZOMG coffeescript (or whatever) as a default, then you probably should have considered that. Personally, I'm okay with Django core moving slowly, because I can augment it with reusable apps that are able to move a lot more quickly.
You also don't see douchey posts from the Django developers. They generally show respect for competing frameworks, and aren't afraid to be critical of their own. There's a lot to like here.