Just about the second thing he does in that video is to start editing settings.py, where he edits line 14, line 15, line 119, and deletes lines 118, 120, and 121. He then jumps over to urls.py and deletes lines 12, 13, 14, and 15 while uncommenting lines 4, 5, and 16. He makes the observation that he's just going to ignore all of the other crap in settings.py.

That workflow is very particular to a Unix config file. It's, for example, what you have to do if you want to use Tor: you browse slowly through a torrc file that sets every setting with comments explaining what it does, and you uncomment or change these lines depending on what you want to happen.

That's not a bad workflow, but when I'm in a programming language I have a better option: I don't need to think about the world as "here is this monolithic application which I have to configure," but instead I can think, "oh, here are some methods which I might like to use -- methods which make servers listening on sockets with various protocols, and so forth."

The thing about config files is that if you don't embrace the Unix philosophy of "small tool which does one small job well", then the config language can come close to being Turing-complete. But if your config files are Python applications, that's already Turing complete. You don't need to build a new language on top of Python. Why should I be trying to describe in a data structure what my database is? Why make me write a data structure containing 'sqlite3' rather than mydb = django.dbs.sqlite3("filename") ? (There are a couple of reasons, actually -- one of the biggest is that they want to have a 'syncdb' command -- but I'm still not convinced that this is the best way to implement that.)

Django is not a 'monolithic application which I have to configure', but settings are, well, settings - stuff you have to set. Urls.py is routing, you'd have to config it somehow anyway. There is a lot of room of improvement how the settings could be handled in Django to make them more flexible and get rid of that overhead in settings.py and afaik the core team is planning to work on that, but for the moment you take it as it is. Django has a nice learning curve, you get to know how it basically works while writing your first apps, but maybe it's not for you - if you're looking for something raw and lightweight, you can try Flask. If you want a mature framework which solves most use cases for synchronous web programming and you can build powerful stuff on top of that, it's Django.