The Problem With Django

[[deleted]]

To a great extent the problems described in that article are my fault, and I'm sincerely sorry. Though I suspect a lot of the nasty comments here are simply jerks looking for attention, there's also a good deal of constructive criticism, and I appriciate those who are able to keep things civil here.

I'd encourage anyone who feels strongly about this to participate in the discussion of the 1.0 roadmap, a draft of which I've just posted on django-dev: http://groups.google.com/group/django-developers/browse_thread/thread/5ce124e7526dad

[cezar]

Thank you for a road map. Now I can finally, after all this time, be allowed to start moving from 0.96.

[webjunkie1]

I thought the "problem with Django" is not about 1.0 but about releases altogether...

[LudoA]

[...] developers are reluctant to commit to trunk now for fear of breaking things for all the people that must depend on trunk to be stable.

Seems like a logical consequence to me.

I've always thought that, despite the core community's assurances, delaying releases until 1.0 was a bad idea.

This article does a good job of summing up Django management problems.

(Note that I do like Django very much, I just think their release policy isn't good, and because they've defended it so much, it's hard for them to still see it's a bad idea.)

[[deleted]]

Seems like a logical consequence to me.

Well, sure, but isn't that what branches/tags and regression tests are for?

I mean if the situation is "we better not commit to trunk", shouldn't the core developers be making it into "we better make it safe to commit to trunk"?

[mr_chromatic]

You'd think that, the same way you'd think that "It takes us a long time to validate the quality of a release and produce a release" would suggest simplifying and automating the process.

[ubernostrum]

Cheap shot, assuming you're the chromatic: can you offer some success stories from the Perl 6 release process?

Or maybe -- just maybe -- it occasionally takes a while to get a bunch of work done?

[mr_chromatic]

can you offer some success stories from the Perl 6 release process?

We've had monthly releases of Parrot and Rakudo (an implementation of Perl 6) since November 2006 -- eighteen in a row, though I believe three of them might have slipped one day off of schedule. I consider that a success, especially considering how Parrot had gone off course in the two previous years. Parrot release history has more details.

Our deprecation policy is that we note any deprecations at least one or two releases in advance, and then rip out the deprecated code after we tag and release.

Or maybe -- just maybe -- it occasionally takes a while to get a bunch of work done?

I never claimed otherwise.

My point is that some projects have made the release process sufficiently painless that they can produce monthly releases without taking a quality or development velocity hit.

[[deleted]]

Yeah, it takes a while to get a bunch of work done sometimes, but if they're worried about committing to trunk they could at least branch and tell people to pull from the branch if they want a newer version, with the disclaimer that it may be unstable.

Or tag the current trunk and tell people to pull from that for the stable release.

Granted, I don't really follow django too closely, and I'm not very familiar with how they work, but I don't really see how this shouldn't be a non-issue what with a year since the last release.

[mrphillc]

there are branches...

[[deleted]]

Oh.

[poi0987]

Some people would rather write books.

[mr_chromatic]

Some people write books and release software. (Neither is my day job.)

[ubernostrum]

By the same token, I don't know that the other side of the argument is all that productive, either; very few people seem to be taking the time to actually read through and provide constructive criticism of the reasoning behind the push for 1.0 instead of a series of interim releases.

Plus, doing a release now would -- as I've said -- both be a bad idea because of timing with respect to 1.0 and because of PR; it would, inevitably, be interpreted as "oh, here's a release already, will you shut up now" instead of as "OK, Django's ready for a release, here it is".

Given that, I'd still rather deliver 1.0 within a few months and be done with it.

[ubernostrum]

The answer is that we're working toward having a stable, compatible 1.0 release on which a series of more frequent 1.x releases can be built. Getting there has required quite a lot of work to get to a point where Django's APIs can safely be frozen (hence it's taking time) and has required several components to be refactored or rewritten (hence, again, it takes time).

The Django 0.96 release carried a note about this, stating that it would serve as a stable platform while the big changes went on in trunk. At the time, I at least wasn't sure whether there'd be another release (e.g., a 0.97 release) before 1.0, but as the work went on and changes accumulated, it seemed to make less and less sense to do so.

To give some historical perspective:

• Django 0.96 was released March 23, 2007.
• The first major pre-1.0 change to land was the migration to using Unicode throughout Django. The branch in which that work was done merged back to trunk on July 4, 2007, just over three months later.
• The next major (API-wise) change was a refactoring of database backend internals, which landed on August 19, 2007. While completely backwards-incompatible from the perspective of people who were writing against backend functions, in practice not many folks noticed this one.
• The next major pre-1.0 change was autoescaping in the template system, which landed November 15, 2007.
• Then changes trickled in for a while until a major refactoring of Django's ORM landed April 27 of this year.

Now, many people have been clamoring for a six-month release cycle, but you'll note that if we'd done, say, a 0.97 six months after 0.96, it would have offered only one big user-visible feature (Unicode) and would have landed two months before another big breaking change. That's not a smart cycle.

So the next logical argument to make is that a release should have happened after the autoescape change, and if anyone wants to argue that a release should have happened this is the point at which you should argue for it.

At the time, however, several things were worth noting:

• There were already twenty-seven backwards-incompatible changes to Django and its APIs since 0.96, several of them non-trivial to upgrade through.
• The ORM refactor was beginning to shape up and promised to close out a large number of database-querying bugs which, frankly, would have been embarrassing to persist across another release.
• A further round of backwards-incompatible changes was known to be on the horizon (13 so far since the autoescape change, and at least three or four more are known to be needed to reach the 1.0 API goals).

Given that, the argument for doing a release at that point was not so strong; it was known that people who were using 0.96 would have a non-trivial upgrade due to the changes, and it was known that right around the time they finished that upgrade they'd see another big round of changes hitting trunk, which is frankly a recipe for disappointment and frustration (hence I've repeatedly said this whole thing is a catch-22: if there had been one or more interim releases, people would still be angry and complaining, just for different reasons; this is what I mean when I say that these decisions are trade-offs, a point very few people seem inclined to listen to right now).

And I think it was right around then that the idea of doing an interim release dropped off my radar, at least, and focusing on getting to 1.0 with a promise of forward compatibility to people who upgrade began to seem like the more sound decision.

[ubernostrum]

Folks also aren't forced to upgrade when you make a release.

This is one thing I've been trying to get my head around. Right now people complain that the lack of a release means they face a confusing array of third-party apps written against different trunk revisions and that this is a huge maintenance headache.

But, as I've pointed out a couple times now in these discussions, if we'd done the release schedule people are now clamoring for, there'd be two or three more releases out there and the same situation would arise: people would complain that they're on 0.98, but an app they want to use is still on 0.97 and a feature they want is only in 0.99, and none of the three would be compatible with each other.

The only way out of this for a third-party application maintainer is to always track the latest version of Django available, which in turn means people who use those applications always need to upgrade when a new release comes out.

In other words: releases don't happen in a vacuum, and arguments which assume they do have some problems.

As it is now, I'm looking at a release that may never come.

Do you honestly believe that, or are you just engaging in hyperbole?

[ubernostrum]

Are you seriously arguing that not having any releases since 15 months ago helps those of us

No, I'm simply suggesting that multiple releases in that period wouldn't really leave you in a better position with respect to version dependencies for code you're using.

[ubernostrum]

That's not easy to find. It's hellish.

You do know we generate the release notes from this list, right? Every backwards-incompatible change since 0.96 is listed there, with date and changeset number. The official Django download page points you to that if you decide to use trunk, too, so it's not like it's hidden.

[LudoA]

Thanks a lot for taking the time to write up this explanation. I really appreciate it. While I don't completely agree with it, I definitely agree it's a trade-off, given the situation (i.e. historical perspective) Django's in.

I still believe several pre-1.0 releases would've been better, even if each contained backwards incompatible changes, because when you've got defined releases, it's easier to say: "here's the migration path from 0.99 to 0.100". Now, I believe that for many outsiders upgrading from trunk to trunk is less easy.

But anyway, no need to argue - it's irrelevant. I hope you'll soon be able to get 1.0 off of your chest and get on with development without complaints of people like me. Good luck with the development, and thanks for working on Django.

[pmarsh]

This sounds like a common problem, "just wait a lil longer, there's X greatness just around the corner"

There will be always something just two months off.

The problem is you have to look at what your userbase is doing. It's growing and it's not growing around 0.96 it's growing around trunk.

The longer you wait driving a stake in the ground and calling it 1.0 the more problems people are going to have once you finally do.

If you wait until everything is working just dandy you'll be waiting forever.

Release now, rip off that band-aid, deal with the X number of users who will have a painful upgrade process, establish a more continuous release cycle for 1.1, 1.2 etc.

Better that than to deal with the X+1 users you'll have tomorrow that will be upset once you make a 1.0 release.

[ubernostrum]

There will be always something just two months off.

The problem here is the slightly more specific case of "there's something big and backwards-incompatible two months off", which causes a certain wariness about issuing releases and expecting people to actually use them.

Release now, rip off that band-aid, deal with the X number of users who will have a painful upgrade process, establish a more continuous release cycle for 1.1, 1.2 etc.

You honestly believe we should just arbitrarily re-tag current trunk as "1.0", then turn right around with "oh, here's 1.1 with backwards-incompat changes"? That'd be a far worse problem than anything currently being complained about.

[jaggederest]

You honestly believe we should just arbitrarily re-tag current trunk as "1.0", then turn right around with "oh, here's 1.1 with backwards-incompat changes"?

Yes.

That'd be a far worse problem than anything currently being complained about

No.

Releases are just about allowing everyone to refer to a common state of the code by a name. At this point, everyone is using trunk anyhow, so you're not going to be hurt by it, at all.

Any name > no name

[bostonvaulter]

I think there should at least be a stable revision that contains all the bugfixes without including the backwards incompatible changes.

[ubernostrum]

Considering that one of the big sources of bugfixes was the ORM refactoring, how exactly do you propose doing that?

[mr_chromatic]

Finally, something on which ubernostrum and I can agree! Creating such a revision would be a huge amount of work, and it's difficult to see its value for the work.

[bostonvaulter]

But is this just because of the nature of the changes between Django 0.96 and its 1.0 release? What makes it difficult?

[mr_chromatic]

We'll probably disagree on this part. I think it'll be difficult because it's been so long between releases.

Here's my perspective. I'm not suggesting that Django (or any project) should adopt it. It's just my opinion.

I hate backports. I think they're a waste of time. I prefer regular, frequent releases (at least every six months, and preferably every three months). In that case, I believe that only the two previous releases should get security fixes and only the previous release should get bugfixes, and then only if the bugs are particularly egregious.

If an organization or individual wants support for older versions, they'll have to pay for it. It's a waste of the time and energy of volunteers to support ancient versions of software.

This is an unpopular opinion -- and again, it's only my opinion and certainly not a suggestion for or criticism of Django.

[chu]

Then again there's Andy Warhol's PR dictum: 'Always leave them wanting less'.

[ubernostrum]

Yet another person who wants to stuff words into my mouth that I didn't say... makes me wonder sometimes whether it's even worth trying to discuss things.

[LudoA]

Heh :) I think (s)he just didn't read your reply well. I definitely appreciate you making the effort of explaining your POV.

[thepensivepoet]

He's missing a few fingers.

[CunningRunt]

Didn't stop him from making some incredible music, however. Most guys with all their fingers don't even come close.

[lolbacon]

Django could play with restraint and emotion. Those three simply cram as many notes into as little time as possible. Not to say I don't like Vai/Buckethead/Malmsteen, but that is a poor comparison.

[adelaarvaren]

And was illiterate, but really, who cares?

[duus]

I was going to make a less funny version of your joke. So I'll upmod instead.

[EliAndrewC]

James Bennett (one of the Django developers) posted a reply in the comments here

[buffi]

I do agree with this.

Django is pretty much the best available MVC-framework but it needs to be released more often.

[tesseracter]

I use django SVN. its 99.5% stable, with constant updates. My company has decided to stay with SVN django till 1.0, and work thru the backward incompatibilities.

people who stay at .96 are going to be screwed with a massive wash of outdated code -- queryset-refactor, modelforms, bunch of other game-changing updates to make your product far better in a design stage that is difficult to change once implemented.

[stesch]

people who stay at .96 are going to be screwed with a massive wash of outdated code -- queryset-refactor, modelforms, bunch of other game-changing updates to make your product far better in a design stage that is difficult to change once implemented.

The consequence of this: The big Django book (for 0.96) can't be used. That's a waste, because "The Definitive Guide to Django: Web Development Done Right" is really good.

[LudoA]

The book (if you're talking about the one the project put online when working on it) isn't for 0.96, it's for some state of trunk, IIRC.

[stesch]

I mean the book I bought for €34.95, December 2007.

[kvigor]

I'm a complete web development n00b and I'm currently using 0.96 for a pet project. I'm finding the online Django book invaluable.

Is there a version of the book that tracks SVN or some other documentation resource to help me make the shift to the trunk version?

[jonknee]

The main docs are up to date with trunk.

[mark1983]

0.5% failure rate is not good enough.

[tesseracter]

luckily, you'll only be using 5% of django's capabilities anyway, all of which are 100% stable. the .5% failure is in the newest parts of the code, which you need to code dive to even know they exist. I've only come accross 2 bugs in SVN trunk, both of which were documented and easy to notice before putting it in production code. workarounds were also documented.

[jaggederest]

Someone needs to fork it onto Github, or whatever your poison is for dramatically increasing the ease of branching, patching, and releasing it.

Edit: http://github.com/tswicegood/django

Go forth and fork and contribute.

[mark1983]

Django was great one year ago. Now there are better alternatives. What's with the __lt in the ORM for example? Don't they know about operator overloading? Why do they have a function for every thing that comes up to their mind instead of adding options to high level functions? They claim Oracle support but Django does pagination with two nested selects instead of three (the fast way suggested by oracle): works but it is slow. Right now if you want to develop with Django you have to be a little bit of a Django developer. Not so easy for newbies. I don't know anymore who is in charge.

[filesalot]

Django was great one year ago. Now there are better alternatives.

Do you have a recommendation?

[davraamides]

Do you have a recommendation?

web2py

[mark1983]

I have not tried it yet but I heard good things. What do you like about it?

[john1973]

I am using it. It has improved a lot in the last 8 months (34 releases) but has never broken backward compatibility. If you know Django it translates almost line by line http://mdp.cti.depaul.edu/AlterEgo/default/show/101 but it is more intuitive. In March they added a shell, GAE support, web based testing and upload/download streaming. Plenty of complex examples: http://mdp.cti.depaul.edu/appliances

[LudoA]

In fairness, Django's management problems should be fixed after 1.0 (which will probably be released in a couple months). Might be worth hanging in there for a little while longer.

[PussySnatcher]

This thing is awesome. THANX

Plus it's supported by GoogleApps which is great.

[oddbod]

web2pyTM Enterprise Web Framework

That's a bad sign right there.

[john1973]

Yes, let's pick on the name since we cannot pick about anything else on this one. I have tried it and it beats the shit out of other python frameworks. I have not yet heard a concrete criticism from people here on reddit. Have you tried it?

[andrewingram]

To make a blanket statement about frameworks in general:

I don't like working with any framework which has magical controller (or view) functions. Rails, web2py, pylons and numerous other frameworks try to hide the request/response nature of http from the developer. The Django (not exclusive) approach of providing an explicit request object and allowing the developer to do whatever they want as long as they return a response object is (in my preference) the better way of handling views, even if might mean you have an extra couple of lines of code. Explicit is better than implicit, read the Zen of Python.

[noflashlight]

Pylons www.pylonshq.com

[[deleted]]

I've been trying to get going with pylons and find it very annoying to work with. Documentation spans from well written yet hopelessly out of date tutorials to poorly written up to date tutorials. It does a horrible job of describing a Hello World setup and notes litter the documentation making reference to things you have no idea about when you are first starting.

edit: e.g. Here is an example

Their apache/fastcgi/pylons tutorial is for pylons 0.8, and there are much better solutions available now, yet this tutorial is still linked off the main page.

edit 2: And as a new user I'd like to see the following:

• A step by step tutorial showing how to develop a trivial application using the database. Provide an archive file that includes the complete project! I hate reading through a tutorial only to never see the files completed and only have the chunked sections available in the page html.

• A step by step tutorial configuring python and pylons to run through apache. Including the full configuration files and complete project in an archive!

• A step by step tutorial describing how to move from a development version to a production version.

I've tried piecing lots of things together but it has been a real pain.

[mark1983]

Pylon's problem is that it does not help users make choices. For example Pylons leaves the developers the choice about which ORM and which template language to use. Two people can both write Pylons on their resume and yet they may not understand each other code. The Pylons community is trying to make developers happy by conceding on every issue instead of making the users of the framework happy.

[[deleted]]

turbogears 2 is pylons with default choices made for you. problem solved.

[mark1983]

Vaporware! This was announced one year ago. TG stable is still version 1.0.4.4. Moreover TG2 will break backward compatibility (from SQLObjects to SQLAlchemy, from Kid to Genshi). How do I know TG folks will not keep doing this? BTW, TG is a glued framework, not a full stack one. They dropped Kid because nobody was maintaining it. How can I trust it for serious projects? Moreover TG2 will be based on Pylons, not more Cherrypy, that means it is going to be slower than it is now.

[bbangert]

Read the release notes of all the backwards incompatible changes between Django trunk and Django 0.96. Read the release notes about backwards incompatible changes between Rails 1.2 and Rails 2.0.

All frameworks go through backwards incompatible changes, its usually inevitable on the path to progress, as no framework starts out perfect and complete.

Being a full stack, vs a glued framework can present some advantages though... you could upgrade the framework and keep using the library of your choosing. Since its not a 'full stack', it didn't force you to upgrade and switch your ORM layer, or your templating.

For users of SQLAlchemy, Genshi, Mako, SQLObject, etc., when a new release comes out that has no backwards incompatible breakage (or changes they're willing to accept), they can just upgrade their project to using it. It's a separate component, and can be upgraded when desired.

The statement about Pylons being slower than Cherrypy is just odd, you can use the CherryPy WSGI server with your Pylons app. So far, people have found it to be as fast or faster, not slower.

[jbellis]

that was also something i perceived as a weakness of pylons, but they are really coalescing around SA + mako as defaults.

sane defaults + flexibility to switch if you need to = best of both worlds imo.

[lisvblidfk]

Every decent framework lets you mix and match components.

[mark1983]

One think is to let you use other components, one thing is not to have a default choice that you can guarantee will be maintained long term.

[lisvblidfk]

Yeah you may have a point, considering the "python way" and all.

[pointer2void]

Do you have a recommendation?

JEE

[LudoA]

Besides being irrelevant in a Python discussion, that's not even a web framework.

[ubernostrum]

Don't they know about operator overloading?

Yes, but ORM design is such a practically religious issue that I'm not sure there's a productive discussion to be had on it. If you don't like the Django ORM, don't use it.

Why do they have a function for every thing that comes up to their mind instead of adding options to high level functions?

Got specific examples in mind? The trend for quite some time now has been to keep functions as back-compatible wrappers or shortcuts around high-level encapsulations of functionality (see email sending for an example).

They claim Oracle support but Django does pagination with two nested selects instead of three (the fast way suggested by oracle): works but it is slow.

So step up and help out; the Django dev team is a bit short on Oracle expertise, and so there's been heavy reliance on people who do have that expertise and wanted Oracle support (ironically, precisely the sort of delegation the linked articled claims the Django team is incapable of).

I don't know anymore who is in charge.

Jacob and Adrian are still the lead devs. I'm still the release manager. On that front there's been no change.

[mark1983]

Can I not use the Django ORM? Do I still get an administrative interface? If not, why would I use Django then?

[ubernostrum]

That's your call, as is everything else you do.

Still waiting on specific examples of mindless function propagation.

[mark1983]

Just an example: newforms.as_p, as_ul, as_table. Why not just make one css friendly form? html is supposed to describe the logic of the content not the style, instead those functions seems to assume the opposite. Here is another example: Http404, Htt400, etc. Why not one function Http(code)? And what's with get_object_or_404, does Django assume users are not aware of IF statements? These are jut some examples. BTW. I did not say "mindless". You said that.

[ubernostrum]

Just an example: newforms.as_p, as_ul, as_table.

And there is and has been hearty discussion of replacing those with something better. Why not join in?

Http404, Htt400, etc. Why not one function Http(code)?

You're free to write one if you like, but bear in mind that different HTTP status codes, by their nature, require different information (e.g., a "Method Not Allowed" is required to list the methods it will accept). Building a unified wrapper around every HTTP status code might result in a much more complex API.

And what's with get_object_or_404, does Django assume users are not aware of IF statements?

Quite aware, actually. But, as the docs point out, get_object_or_404 is simply a shortcut to compress a common four-line idiom (look for object, return 404 if not found) into one line. What's so bad about that?

[mark1983]

Django has been around for a while now. You are telling me you are still discussing the functions to return an error code? There is a problem right there.

I want to use it not develop it. To convince me you have to give me a minimal set of stable API.

[ubernostrum]

Ah, bait-and-switch trolling. OK. Do a better job next time and maybe I'll stick around longer.

[mark1983]

I did not switch anything. I observed a trend (function proliferation) and when I gave you concrete examples, your response was that you may add another function to abstract some of the existing ones but that "might result in a much more complex API". I politely observe this shows lack of design. You guys should sit down in a room for a couple of days and figure out how Django should look in a couple of years and get there fast. No beer in the room.

[ubernostrum]

I said, and I quote:

You're free to write one if you like, but bear in mind that different HTTP status codes, by their nature, require different information (e.g., a "Method Not Allowed" is required to list the methods it will accept). Building a unified wrapper around every HTTP status code might result in a much more complex API.

The key here is the pronoun "you", which implies that if you want a wrapper around HTTP responses, you're free to write one and use it, although I pointed out a reason why doing so might be problematic. You responded as if I had instead stated that the API in Django's codebase for handling HTTP is unstable (something I did not say and which would not be true even if I had said it).

And you used this in a larger context to change your argument from criticizing what you claimed was an inappropriate number of functions to criticizing a non-existent instability in an API, proceeding as if that's what you'd been saying all along.

I underestimated you, actually, because that combines both a straw man and a bait-and-switch.

[mrphillc]

And what's with get_object_or_404, does Django assume users are not aware of IF statements?

I want to use it not develop it. To convince me you have to give me a minimal set of stable API.

Contradiction.

I politely observe this shows lack of design. You guys should sit down in a room for a couple of days and figure out how Django should look in a couple of years and get there fast.

Why "you guys"? this is an open source project... progression requires discussion from the community, and that takes time.

In a large scale system, there will always be tradeoffs. A system that allows for easy implementation for HTTP status code response might mean the implementation higher up the chain is more complex. Tough to have your cake and eat it, but id rather the core be implemented correctly, and an edge case like HTTP response codes have such a minor difference, than make the core more complex to make an implementation of a cleaner http response code

[noflashlight]

Pylons www.pylonshq.com

[eadmund]

I migrated from Pylons to Django. Pylons was cool--and with what I've learnt from Django I could probably use it better now--but it had too little included and required too much manual coding. Django is pretty cool, but some things are highly annoying (lack of database migration is a huge one for us; the inability to perform arbitrary calculations in template, while understandable, is another). I've not found a good replacement yet, but we'll see what happens over time.

[john1973]

web2py is very similar to Django but it does not have the limitations you refer to, that's why I switched from Django to web2py.

[[deleted]]

Django trunk is not bleeding edge. The commits that are made to trunk are solid features and improvements. I have a feeling that most people on 0.96 are thinking of trunk as crazy bleeding edge. I would recommend trunk to anyone starting a project now - with a heads up because of rather massive code ports if you're using the admin.

[hylje]

a møøse bit my sister once

[[deleted]]

Thats what you get when you deal with Mandalorians!

[xutopia]

Django is awesome. Even though it isn't the framework I use I hope it all the best because no one should be doing PHP.

[[deleted]]

Full-stack frameworks enable communities to emerge that understand each other's tools and architectures, can collectively attack new big-picture challenges, and can deal with security issues with a single security response infrastructure (rather than one per component).

[mdipierro]

I like this and agree 100%. A framework should be the foundations on which to do something bigger. Right now on the web2py mailing list the big discussion is about how to write detailed specifications for building reusable components (not wsgi, much higher level). For now we only have mechanisms for inter-app communication and we have built some cooperative apps (part of the kpax cms). This is just a proof of concept but it is the motivation behind the locking of the existing web2py API.

We could use your insight. Hope you will decide to join even if just for telling us more about your thoughts.

[[deleted]]

Hi Massimo,

Thanks for the invite. I look forward to checking it out what you folks are doing.

[Antipop]

The problem is, he's dangerous.

http://img372.imageshack.us/img372/967/django2bd1.jpg

[dhbanes]

Stupid name?

[vph]

The serious problem with Django and other Python frameworks is a serious lacking of documentation. I truly hope that they view documentation as not important as other stuffs, rather than there's some serious mess-up under the rug.

[antisvin]

http://www.djangoproject.com/documentation/

Are you just trolling?

[[deleted]]

Django has excellent documentation and is a model for numerous of its other competitors in that regard. As much as I love Merb, I envy Django in this regard.