Thanks for your kind reply, Malcolm. I think I'll just take the "roll up your sleeves" way and dive in. Try to poke at the code, change things, see what happens (as in, what is affected by the change I've made, discover dependencies and usage of code pieces), and maybe give things like backends (sessions or db, don't care) a try.
I've been using django for a while now, and would eventually like to give something back. Maybe trying to give in to the hype and build my way to get django sessions working on GAE would be a nice learning process? I bet something will be published before I can get my head around how a backend works, but it should be a nice personal experience. Aside: While typing this I discovered ticket #7008 [1] [1] http://code.djangoproject.com/ticket/7008 El sáb, 12-04-2008 a las 21:34 +1000, Malcolm Tredinnick escribió: > > On Sat, 2008-04-12 at 11:15 +0100, Chris Hoeppner wrote: > > Hi there, > > > > As the subject says, I'd love to learn more about how django works > > internally. I've been doing python stuff for about a year or more, but > > still can't seem to get my head around a big part of the black magic. I > > wonder if there's something I'm missing? > > If you're asking "is there a silver bullet", then... well... no. > > There are at least a couple of ways to become familiar with a random > bunch of code that you're interested in. One is to start out with a > problem, say, a traceback and work outwards from there. The traceback > will give you a call stack and then you can investigate the code > surrounding that to work out what might be going on. Another approach is > to follow data paths. Track a piece of data as it enters the system all > the way through until it exits. > > In Django, that means tracking a request. So start from one of the > request handlers (django.core.handlers.wsgi, for example) and trace > through what happens to the incoming HTTP request. This will be > decidedly easier if you have a small application that interacts with > Django, because at some point URL resolution will take place, then a > view function will be called, you might access some model stuff > (entering the ORM) and then it's back to the handler for returning the > response. Without an application of some sort being involved, you won't > be able to trace the path from request to view to ORM to template, etc. > > Alternatively, although Django is large codebase, most of the components > are reasonably self-contained. Pretty much all the directories under > django/ represent self-contained pieces (utils/ -- containing things > that are used across Django's internals -- is the real exception there). > So you could pick a directory with an interesting sounding name and > start reading the code. Split up django/db into a couple of pieces: > django/db/models/ and django/db/backends, since they are slightly > different responsibilities. > > Your question is a little general, so if you have some specific area > you're interested in, or if you're trying to work out which piece is > responsible for some piece of functionality, ask a more specific > question. If you're just wanting to learn about the code in general, > though, the only trick is to roll up your sleeves and dive in. Learn > about a little piece at a time and you'll slowly build up knowledge. > > Regards, > Malcolm > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
